Bill,
> >Line 216 introduces the possibility that
the TC Administrator might
> > create aliases for some or all existing
artifacts.
> >
> > Please don't[1].
> >
> The intent is to allow a full consistent naming structure (on
> docs.oasis-open.org) even though some content is there already. The
> alternative is to remove support for the old, promised-persistent
URIs,
> or to do another domain (documents.oasis-open.org?). I'd say this
nmight
> be the best of a set of bad choices.
No, the best choice would be to leave
things be and use the ASIS for new (and possibly
currently-in-development) endeavors,
So, I whole-heartedly concur with Norm's
admonition.
Please don't.
> >Line 263 abbreviates "requirements";
line 265 abbreviates "specification".
> >
> > Please don't. The few characters saved pale in comparison
to the
> > confusion caused by abbreviations, not only for non-English
> > speakers, but also for those of us who have to remember,
> > "'requirement' is abbreviated, but 'profile' isn't,
is that right?
> > Or is it the other way around?"
> >
> so is "docs.oasis-open.org" OK? :-) Good suggestion.
docs.oasis-open.org is just-fine-thank-you-very-much.
Please do not change that. It is already
in use. Norm's comments related to the other
abbreviations used as metadata tokens.
docs.oasis-open.org is a domain name.
Changing that will only serve to dilute
the brand.
> >Line 275 introduces dates of the form "YYYYMMDD".
> >
> > Can we please the ISO standard YYYY-MM-DD format? And does
this mean
> > that I can't use "23 Feb 2006" as the date on
the cover page of my
> > specification?
> >
> Alas, the hyphen issues strike again. And 23 Feb 2006 is fine by me,
but
> the metadata format also needs to be there. Do you have better separator
> character than hyphen to use in artifact names and URIs?
Can we please, please separate the filename
gorp from all other expressions of metadata? I would
certainly hope that the expression of
a date on a cover-page of a specification could be of the
form that Norm suggests (DD Mon(th)
CCYY) . I prefer that form in all expressions as it is
the least likely to be confused.
> >Lines 438 and 439 say that the "stage"
is optional for schema and wsdl
> > artifact types
> >
> > Why? Where is the rational for this. What makes them different
from
> > catalogs or guidelines or any other type of artifact? If
I invent a
> > new artifact type, do I get to say if the stage is optional?
If not,
> > who does? The TC administrator, I assume, but it isn't
stated.
> >
> > I think it's wrong to make the stage optional for some
types and not
> > others.
> >
> Original motivation, I think, was to allow a single schema namespace
URI
> without requiring a change for each developement version of a spec.
This
> is existing practices in a number of TCs.
IMO, this is a classic example of where
it makes sense to separate out the namespace URI from the
URI of the resource(s) that it represents
and why it is considered good practice to have a
namespace document (RDDL) that describes
the namespace as opposed to having the schema
or WSDL document at the end of the namespace
URI. Please DO keep in mind that there
is not necessarily a 1:1 correspondance
between a namespace and a physical schema
document.
However, IMO, it also points out the
folly of forcing the metadata to be expressed in the filename.
IMO, the practice adopted by the W3C
for providing:
This
version: [dated URI]
Latest version: [persistent URI]
Previous version: [dated URI]
is something that OASIS should long
ago have adopted as well. If I embed the metadata within the
artifact, yet make it available via
some persistent URI (regardless of what its current status is), then
it means that in such cases where ONLY
the metadata has changed, that the resource's URI
need not change. This is "A Good
Thing(tm)".
Cheers,
Christopher Ferris
STSM, Software Group Standards Strategy
email:
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
