MHonArc v2.5.0b2 -->
oasis-member-discuss message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oasis-member-discuss] Re: Review of AIR = ASIS, possibly mandatorypolicy?
One more point on the draft ASIS:In section 7.1, buried in a long treatise
of how RFC3121 needs to be changed, it says this:"OASIS namespace declarations pursuant
to [XML NS 1.1] or [XML NS 1.0] MUST use either this class of identifier
or a URI as described in Section 6.2."It has been noted by me and others that
the reference to Section 6.2 should be changed to 7.2. However, I think
that a statement of this import should actually be captured in
section 7 as preamble to 7.1 and 7.2.e.g.7 Uniform Resource Names and Namespaces
(Normative)OASIS namespace declarations pursuant
to [XML NS 1.1] or [XML NS 1.0] MUST use either the URN class of identifier
as definedin RFC3121 and constrained by Section
7.1, or a URI [RFC 3986] or IRI [RFC 3987] as described and constrained
in Section 7.2 below.Note that I have added explicit references
to the relevant RFCs for URI and IRI (of which no mention was made in thedraft in the section related to namespaces)I frankly find the guidance given in
the namespaces section to be rather skimpy on guidance to TCs. Also, in
light ofthe fact that section 7.1 explicitly
states that URN resolution services will NOT be provided by OASIS, that
it mightbe wise for the TAB to make a recommendation
as to which form of namespace identifier is preferred, along withsome rationale as to what motivates
such a preference, or at least a discussion as to what the pros and consare for using one form or the other
such that the TCs can make an informed decision.There is also no mention made of the
use or a namespace document. Quoting the draft finding [1] of the W3C TAG:"[WebArch
Vol 1] says that it is a Good
Practice for the owner of a namespace to make
available at the namespace URI “material intended for people to read and
material optimized for software agents in order to meet the needs of those who will use the namespace”.
"I happen to agree with this approach.
Some TCs are adopting such practice, yet the ASIS offers no guidanceon this practice. IMO, I think that
the ASIS SHOULD do so. At the VERY LEAST, the ASIS SHOULD includea reference to the WebArch and to the
draft finding and RECOMMEND that TCs at the very least reviewthat material and make an informed judgement
as to whether they too think that a namespace documentis "A Good Thing(TM)".
You never know, but maybe, just maybe, a namespace document just might
be a goodplace to contain metadata about a namespace,
which IMO is just as valid an artifact as any other.[1] http://www.w3.org/2001/tag/doc/nsDocuments/Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295Christopher B Ferris/Waltham/IBM@IBMUS wrote on 02/24/2006
07:15:44 AM:
>
> Comments inlined below.
>
> Generally, a big +1
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> "G. Ken Holman" <gkholman@CraneSoftwrights.com> wrote
on 02/23/2006
> 09:30:43 PM:
>
> > At 2006-02-22 17:01 -0800, jon.bosak@sun.com wrote:
> > >UBL TC,
> > >
> > >Forwarded as requested.
> > >
> > >Jon
> > >------- Start of forwarded message -------
> > >Date: Fri, 17 Feb 2006 16:11:17 -0800
> > >From: James Bryce Clark <jamie.clark@oasis-open.org>
> > >Subject: [chairs] Draft ASIS under review: mandatory
policy?
> Please review
> > > and comment by 1 March
> > >To: chairs@lists.oasis-open.org
> >
> > Regarding:
> >
> > http://www.oasis-open.org/committees/download.
> > php/16546/ArtifactStandardIdentificationSchemeForMetadata-1.0.1.pdf
> >
> > Line 352 - this is an action item for OASIS staff, not an aspect
of
> > this standard ... the "SHALL" in this jumps out at
me as totally
> > unnecessary. By the time most people have read this document,
this
> > action item should have long been acted on. Unless, of
course, I'm
> > misunderstanding the sentence in which case it should be
> > rewritten. But, if this updating is a one-time action,
is it on the
> > part of those who maintain the The OASIS Document Templates?
When
> > will the decisions be incorporated into the templates (note in
my
> > postscript below that I've been working on the DocBook XML
> > templates)? A lot of UBL 2.0 is already in development
... will a
> > change in the templates while writing a new specification mean
that
> > work in progress would become non-conforming?
>
> I raised roughly the same points in my feedback. There needs to be
a lot
> more clarity around transition rules and grandfathering of existing
> work.
>
> >
> > Lines 354-386 - I'm not sure what is meant by "consistent
tabular
> > form", especially since it looks like the RFC822-styled
prompts and
> > values (which is distinctly not "tabular" (I interpret
this as
> > systematic aligned rows and columns; the columns are not aligned
in
> > RFC822-styled mail headers). I don't see guidelines as
to how this
> > "consistent tabular form" is to be rendered in various
> > renditions? Should it be an HTML table? If in a PDF
table, with
> > visible cell borders (perhaps, somewhere in the front
> > matter)? Should it be also in HTML <meta> elements
(I think so;
> > though I don't know how I'll do this in DocBook)?
> >
> > Line 408 - I think ECMA-6 is a poor choice for a 128-byte character
> > set because of the two ambiguous "alternative graphic character
> > allocations" (6.4.2) ... I suppose this is covered because
the
> > exclusive list is indicated, so I guess this isn't a problem.
Why
> > use ECMA and not, say, ISO-646? Actually, I guess it has
the same
> > issue. Therefore, why bother citing anything and not just
list the
> > characters ... would this in fact cause problems with a mainframe
> > tool that happens to be using EBCDIC? The fact that it
is the
> > correct ECMA/ISO characters when it is being mounted in the
> > repository is fine regardless of how it was written, but given
that
> > this is a *naming* standard and not an *encoding* standard, then
just
> > listing the characters should be sufficient and any mention of
> > character set is probably unnecessary embellishment.
>
> +1
>
> >
> > Oh, I just found the reference to <meta> in HTML in section
6.4.1 ...
> > though it isn't an exhaustive list of the metadata. If
ASIS is going
> > to the trouble of listing all of the metadata components, then
> > perhaps these should be mandatory XHTML metadata entries as
> > well. Actually, not *just* XHTML, but for every rendition
an example
> > is needed of what it is to look like ... otherwise, how would
I be
> > able to modify the DocBook XML templates in a conformant fashion?
>
> I raised this point as well.
>
> >
> > Line 532 - Absent here are ZIP and TAR/GZ files (though I don't
know
> > what to do about them) ... I think they should be recognized
...
> > perhaps have a companion ".txt" file (though I hate
the idea of
> > having information in more than one file)? Though perhaps
having a
> > companion ".txt" file for all binary file types will
be both
> > sufficient and consistent, but line 350 provides a list of required
> > metadata elements "The following metadata MUST be associated
with
> > each Artifact...", so it would have to be documented that
for every
> > binary file (or file without a human-readable rendition) that
one can
> > expect to find a .txt file with the meta data. That could
add a
> lotof files!
> >
> > Line 596 - Shouldn't this be a reference to Section 7.1?
> >
> > I think it is going to be difficult to get Joe and Jane
> > StandardsWriter to accurately divine what values for properties
in
> > these guidelines apply to documents they create for their committee
> > ... could the guidelines require each TC to publish somewhere
visibly
> > in their work pages what the choices are for metadata properties
> > related to all documents for that particular committee? That
way two
> > people in one TC don't end up making different decisions based
on
> > their respective interpretations of these guidelines. I'm
learning
> > that one really has to spoon feed stuff like this to people who
are
> > made responsible for creating things ... they won't take the
energy
> > to have to interpret administrivia and distract them from their
> > technical writing.
> >
> > So, I then took a look overall at ASIS and I realized that I
really
> > couldn't effectively distill what the important guidelines would
be
> > for, say, the UBL TC or my HISC subcommittee of UBL.
> >
> > Consider for example the tree of file with the following directory
> > at the apex:
> >
> > http://docs.oasis-open.org/ubl/cd-UBL-1.0/
> >
> > ... the artifact in that directory has to be named "index.html"
in
> > order to be properly displayed by the server when the directory
is
> > referenced. Does this mean that the directory has the artifact
> > name? Probably, but there are 244 files in that tree. Are
*all* of
> > them (except the necessary exceptions for the directory "index.html"
> > files) to be named with these ASIS guidelines? If none
of them are
> > used outside of the context of UBL 1.0, why would the artifact
naming
> > guidelines apply? I can see them applying to the apex directory
and
> > to any ZIP file that would be used out of context of the
> > directory. That's it! The difference is, when is
a committee
> > artifact found *only* in a given context and when is a committee
> > artifact allowed to live outside of that context? The apex
directory
> > can be found in any context, so its name follows the artifact
naming
> > guidelines. The ZIP or TAR/GZ packages of the directory
can be found
> > in any context, so its name would also follow the guidelines.
And,
> > as above, I suppose also an associated text file with the metadata
> > for those compressed packages.
> >
> > This would greatly simplify a committee's work. I had the
> > responsibility for creating the directory at the apex:
> >
> > http://docs.oasis-open.org/ubl/cd-UBL-1.0/fs/
> >
> > There are 99 files just in my subtree. BUT my subtree isn't
ever
> > found outside of the context of the UBL 1.0 deliverable, so none
of
> > the artifacts in that subtree would be out of context (or should
be
> > out of context, of course they might be if someone made copies
them
> > without copying the other files, but when they are in context
on the
> > UBL web site inside of the UBL 1.0 deliverable, they are
>
> I have tried, unsuccessfully apparently, to make exactly this case
in the TAB
> before I retired my position. I maintained, consistently, that it
was folly
> to try to imbue filenames with metadata, that all we needed to do
was to
> use the web as it was intended.
>
> I recommended the use of RDDL, and produced a microformat for the
> OASIS metadata that could be embedded in the RDDL document which could
> link to the actual artifact.
>
> I also pointed out the folly of trying to force version numbering
> into the file names as it would conflict with use of a version control
> environment such as CVS or SVN, which I had been lobbying OASIS to
provide
> its TCs throughout my tenure. We're now getting close to the point
> where such facilities will become available to TCs and IMO that will
> likely result in conflicts with the ASIS draft as currently written
> because a document in the SVN store will not have a filename reflecting
> the version number unless you explictly create a new entry in the
> repository for each successive revision of an artifact, which pretty
> much defeats the whole purpose of a version control system.
>
> > correct). The burden of going through all 99 files of my
subtree and
> > renaming each and every file to follow the artifact naming guidelines
> > (examples, graphics, linked specifications, etc.) would deter
me from
> > going through the effort to produce everything that is needed
by the
> > readers. I ended up with 99 files because that tree of
hyperlinked
> > documents and examples is what I felt the reader needed. If
I had to
> > go to so much effort for all 99 files, I would have produced
fewer
> > files without as much information and the reader wouldn't have
been
> > as well served.
> >
> > I believe OASIS has to make the process of writing specifications
> > *easier* in order to help people with limited time involved in
the
> > already lengthy process of writing to produce something that
can be
>
> Bingo
>
> > used. Therefore, the burden should be focused to accomplish
the goal
> > and not so broad as to deter contributions. As I said above,
I think
> > it is sufficient that the burden of identifying artifacts at
the apex
> > directory and any files that might be found outside of the context
of
> > the apex directory.
> >
> > Perhaps it is easier than I thought and I was just confused by
the
> > lack of examples. In particular, since I chair two subcommittees
and
> > one task group below the UBL umbrella, are these distinctions
> > irrelevant? Are my work products just considered UBL work
products?
> >
> > . . . . . . . . . . Ken
> >
> > p.s. regarding the templates, I put 33 hours into modifying Norm's
> > former DocBook guidelines for OASIS standards into a new set
of
> > guidelines to try and help writers using XML, by including all
the
> > sections matching the Word and OOo templates found in:
> >
> > http://docs.oasis-open.org/templates
> >
> > You can find these new stylesheets and complete publishing package
> details in:
> >
> > http://docs.oasis-open.org/templates/DocBook/spec-0.4/oasis-
> > specification-0.4.html
> >
> > In order to try and get my UBL colleagues to use XML to create
the
> > standards documents, I tried to make this environment as turnkey
as
> > possible with detailed examples of what to do. Hopefully
by doing
> > so, members would be more encouraged about writing specification
> > documents since the environment would produce the desired
> > presentation without the writer having to think about it. To
prove
> > to myself the environment is functional, I've since used the
> > environment to create the two work products announced in:
> >
> > http://lists.oasis-open.org/archives/ubl/200602/msg00062.html
> > http://lists.oasis-open.org/archives/ubl/200602/msg00069.html
> >
> > So, your decisions impact on me by bringing my latest work to
the new
> > ASIS standard, and I don't see enough information in there to
do a
> > complete job.
> >
> >
> > --
> > Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17
> > World-wide on-site corporate, govt. & user group XML/XSL
training.
> > G. Ken Holman
mailto:gkholman@CraneSoftwrights.com
> > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
> > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999
(F:-0995)
> > Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc
> > Legal business disclaimers: http://www.CraneSoftwrights.com/legal
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS
TC that
> > generates this mail. You may a link to this group and all
your TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]