ASIS comments

All,

 

I would like to highlight what my concerns are with this
document. In short I only have a few objections to the set of metadata that has
been identified, what concerns me the most is the process and tracking of it as
well as guidance I consider to be missing that should be here. 

 

I do not believe this document is complete and it should
not be adopted in its current form. 

 

Here is an outline of my biggest concerns (in no
particular order):

 
I fail to understand the
     distinction between and relation of Artifact, Artifact Identifier,
     Artifact Name, Filename and the seemingly undocumented specification-id.
     

 
Don’t create
     retroactive aliases for existing documents that match this guideline,
     which seems a poor use of time and will result in confusion and possibly
     naming collisions. 

 
I find the division between
     section 3 and 4 confusing, it would be much more readable if these were
     combined. 

 
These guidelines should be
     updated to decrease not increase the chance of naming collisions as I
     believe they do today. 

 
Unclear motivation for the
     requirements that subtrees should be made and maintained (even
     retroactively) at http://docs.oasis-open.org/[tcShortName] AND
     http://docs.oasis-open.org/[product]. This has a great potential to cause
     naming collisions (especially for any TCs who have a product with the same
     name as the TC) and will make the relation between a TC and their work
     products ambiguous. 

 
The guidance that tcShortName
     should not contain a – character completely ignores the reality of
     how many TCs already do, this requirement should be removed.
     

 
There is no real guidance on
     namespaces which is an important topic (at least in every TC I have ever
     participated in). 

 
Should prescribe the use of a
     namespace document as noted here [1]. Today RDDL is a good solution that
     would meet this requirement and should be explicitly described as an
     available option for TCs to use. The use of RDDL should be described in
     the document and examples provided. Likewise templates should be
     established for use by TCs that match the final requirements within this
     document. 

 
The guidance on URN contains
     comments on changing RFCs that is inappropriate in this document and calls
     into question the value of the URN section as a whole, e.g. the
     normatively referenced RFCs are effectively declared out of date.
     

 
Examples throughout the
     document are incomplete. The document could be much improved by
     incorporating examples from a variety of active TCs. 

 
There is far too much power
     of decision making given to the TC Administrator with no guidelines for
     how they interact and decide issues with the TC Chairs. This especially
     concerns me as in practice I have already seen a TC Administrator
     “go dark” when a TC made a specific request, we effectively
     got no action or status for nearly a month. Giving authority over to
     decide metadata values that must be included in file names seems like it
     would greatly slow down the work of a TC from this experience.
     

 
Why is no guidance on
     including the metadata in XML given in section 6.4.2? All it covers is the
     use of XHTML. Are we expected to include XHTMLH meta elements in every XML
     doc a TC produces? That seems inefficient, why wouldn’t a schema be
     made to cover the OASIS metadata that could be used instead?
     

 
No process is established for
     central tracking of this metadata. This disturbs me as it is unclear to me
     how anyone would ever get an answer to what value they should use for a
     component other than asking the TC Administrator. 

 

A few line numbered comments:

 
Line 131, is the reference to
     Proposed Naming needed? When/if ASIS is approved Proposed Naming should be
     updated to point to ASIS. 

 
Lines 216 – 220, this
     does not seem feasible or worth the required effort. 

 
Lines 225 – 240, Norm
     covered this in detail [2] and I agree. This section makes no sense to me
     at all, why do we need so many names that all seem to effectively be the
     same value? The relation of these to each other and the use of the terms
     throughout ASIS confused me more than any other single thing.
     

 
Line 254, you will never get
     a complete set represented here. 

 
Line 272, this would be
     incredibly inefficient. Why not the TC chair? 

 
Line 302, it’s been
     said but I’ll ask again. You are kidding right? 

 
Line 391, please provide
     examples in this section. 

 
Line 413, this is unworkable.
     The artifact identifier components MUST be allowed to include hyphens.
     

 
Lines 437 – 440, why is
     stage omitted for these components? This seems arbitrary and inconsistent.
     

 
Line 448, I don’t
     understand this instruction. 

 
Line 482, how can this be
     enforced and why does it matter? 

 
Line 486 – 487, this is
     gives far too much arbitrary power to the TC Administrator. OASIS wants to
     police all the file names used by the TCs? That does not seem a worthy
     endeavor and will slow the work of TCs and overwhelm the OASIS staff.
     

 
Line 495, please provide a
     complete example to match the required components names here.
     

 
Line 500, please provide an
     XML example in this section. 

 
Line 538, this section should
     start with namespaces as it is a more important topic IMO than URN.
     

 
Line 559, why is there a
     specification-id if it is always supposed to be product? 

 
Line 574 – 586, why is
     product better under specification than TC? I don’t understand the
     rationale here at all. 

 
Lines 579 – 588, why
     all of the comments about revising RFCs? That is inappropriate and only
     calls the value of this entire section into question. 

 
Lines 587 – 593, which
     is it? Resolve URNs or not? Why enforce matching the proposed URN
     structure here to the document hierarchy to make them resolvable when it
     was noted that they might not be resolvable? 

 
Line 605, why are namespaces
     not required? Furthermore I think complete guidelines for establishing a
     namespace and the use of RDDL should be included in this section.
     

 

1 W3C Web Arch, XML Namespaces http://www.w3.org/TR/2004/REC-webarch-20041215/#xml-namespaces

2 Norm’s comments http://lists.oasis-open.org/archives/oasis-member-discuss/200602/msg00004.html

 

Marc Goodner

Technical Diplomat

Microsoft Corporation

Tel: (425) 703-1903

Blog: http://spaces.msn.com/mrgoodner/