OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-member-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: ASIS comments



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/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]