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/
|