Chris (and Ian, later on):
Hyphens are one of the few punctuation characters allowed in URIs, as
Ian also noted. One goal of this work was to have machine-parsable
artifact identifiers, and that required using a separator of some
sort.
There were no comments on hyphen use as a separator in the first
review, BTW, so you're not the only one who missed it previously.
bill cox
Christopher B Ferris wrote:
One further comment. Apparently, I
missed
this previously. However, if I read the document
correctly, then for persistent URIs,
the tcShortname is precluded from having a hyphen.
Thus:
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml
is a non-conformant URI, despite the
fact that OASIS Staff has already assigned web space
to the WS-RX TC.
IMO, there is no reason to constrain
the short name within a path component of a URI
with the exception of its use in the
filename as the final path component (as opposed to
a directory listing as can be found
at the end of: http://docs.oasis-open.org/ws-rx/).
I certainly hope that OASIS has no
designs
on changing the status quo. I will only
remind everyone that "Cool URIs
Don't Change" [1]. OASIS has already assigned
some of these persistent URIs,
please
don't change them.
So doesn't that mean that that isn't a cool URI? :-)
My previous note mentioned the problem of the population of
docs.oasis-open.org.
[1] http://www.w3.org/Provider/Style/URI
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
Christopher B Ferris/Waltham/IBM@IBMUS wrote on
02/20/2006
01:01:50 PM:
>
> Jamie/TAB,
>
> Here are my comments on the ASIS draft [1]:
>
> line 264 - according an artifact type of "schema" may present
> problems when there are multiple
> schema artifacts (e.g. a RelaxNG and XML Schema expression of the
> "schema"). Although, it may be
> that "form" could be used as the qualifier. Perhaps the
ASIS should
> make this unambiguous by providing
> examples of a schema that has both an xsd and rng expression.
>
> line 346 - what does this mean?:
>
> Selected metadata SHALL be included in
the name of the
> artifact pursuant to the related separate documents.
>
> First, what does "selected" mean? Does it include the entire
list of
> metadata components cite in this section?
> Some arbitrary selection thereof? Secondly, what does "pursuant
to..." mean?
>
> line 350 - what does "associated" mean? How is such an association
> effected? I am associated with the TAB
> by virtue of being an alumnus. However, I am not IN the TAB.
>
> general - why the seemingly arbitrary use of SHALL and MUST? They
> both carry the same semantic
> according to RFC2119. It would be my recommendation that a single
> form be chosen throughout the docment.
> Note also that RFC2119 makes it clear that the capitalization of
the
> terms does not make a difference
> with regards to the normative intent. "something must do
something"
> means exactly the same as
> "something MUST do something". I think that the document
could use a
> scrubbing to ensure that every
> use of "must" and "may" and "should"
are examined to ascertain as to
> whether they are intended to
> communicate some normative requirement or whether they are in fact
> just considered to be prose.
> If the latter, then the phrasing needs to be changed to make it
> clear that it is non-normative.
> If the document is going to be unambiguous, then it MUST follow
the
> RFC2119 guidelines precisely.
>
> line 352 - that's nice. How are members and TC chairs supposed to
> know when these templates have
> been modified to conform to the requirements of the ASIS? IMO, the
> ASIS cannot be mandated until
> and unless the templates have also been modified accordingly.
> Furthermore, I think that any mandatory
> requirement needs to have a formally defined specification as to
> whether there is any provision for
> grandfathering. e.g. are all subsequently published works,
> regardless of status, required to conform?
> Only those new works produced subsequent to the mandate? That will
> need to be made unambiguous
> in the document.
>
> line 354 - again, what does "associated" mean?
>
> line 370 - is it intended that only the "specification, DTD,
schema,
> or fragment" atrifact types follow
> this requirement, or, (as I suspect) is it intended to apply to
all
> artifact types? What is a "fragment" type? (I imagine
> that it is meant as an XML fragment, but this is not clear)
>
> line 376 - this seems to be inconsistent with the statement above
on
> line 288: "If not present, the value of this component defaults
to
> “en” (English)."
> May it be omitted? Seems to suggest pretty strongly here that it
may
> not be. If so, what purpose does specifying the
> default on line 288 serve?
>
> line 394 - again, associated by what means? I find it difficult to
> understand how a requirement can be stated without
> even suggesting the manner by which it is to be achieved.
>
> lines 401 - I have never seen "ONLY" used in CAPS form like
that
> before. Also, it might help if they
> provided the secret decoder ring value of exactly what the "third-
> level domain" value is. One would
> assume "docs.oasis-open.org" as indicated below. I would
strongly
> recommend a reference to sections 8.1 and 8.2
> be made or that "docs.oasis-open.org" be specified here.
>
> lines 441-444: I think that this is inconsistent with line 402
which
> states that an artifact in "os"
> status SHALL NOT have a revision. I think that it would be simpler
> to simply state that a revision is REQUIRED
> unless the status is "os". I think that making this optional,
> despite the MUST is just opening up for problems.
> I would suggest that it simply be a MUST excepting the case where
> the arifact has "os" status. If I publish
> an artifact for which there are no revisions, and then revise it,
do
> I go back and rename the artifact to reflect
> that it was revision 01? Making this optional is silly.
>
> A value for Revision MUST be included
if there is more than
> one non-identical artifact of the same referenced ProductVersion
of
> a Product. Otherwise a revision MAY be included or omitted.
> Revisions of a single ProductVersion must be unique. If
ArtifactType
> is schema then a value for Revision MAY be omitted in a parallel
> name, similar to those defined in Section 7.4 (Latest
> Version Subtree) below.
>
> line 492 - states:
>
> The relevant required metadata for an
artifact MUST be
> maintained at the default index page for the http scheme URI for
> each product and productVersion to facilitate search and
retrieval.
>
> What form must this take? A RDDL document? I guess I am a little
> confused as there seems to be no guidance as to how the metadata
is
> to be captured in the
> "index.html" page. What does this page look like? Does it
then
> provide links to the various forms of the document that can be
> retrieved? Why is so little of the
> "Required Metadata" that MUST be "associated"
with the artifacts
> included in this "index.html" page's <meta/> tags?
Why wouldn't the
> metadata also be
> exposed visibly on this page?
>
> I have advocated within the WS-RX TC that we use a RDDL document
at
> the namespace URI for the WS-ReliableMessaging specification(s)
> that links to the spec and to the schema (or WSDLs as the case may
be).
>
> http://www.oasis-open.org/apps/org/workgroup/ws-
> rx/email/archives/200601/msg00104.html
>
> Before I left the TAB, I had been advocating a similar course of
> action with regards to the then AIR guidelines. I helped Gil craft
a
> microformat[3] for
> OASIS metadata that was contained in a RDDL document. If you view
> the source of the proposed RDDL documents, you can see how that
> works. Of course, the <meta/> tags could
> be added to capture the Required Metadata as well, so as to
> facilitate/optimize indexing by search engines, etc.
>
> I would actually like to see OASIS incorporate such practice in
the
> ASIS for all namespace URI defined by its TCs, and would also like
> to see this practice extended to all OASIS "products" such
that
> there were a product "page" that provided links to all of
the relevant
> artifacts in RDDL form, with a location to hold all of the
> "associated" metadata.
>
> line 573: section 6.2 does not specify how to construct namespace
> URI. I believe that it should in fact be section 7,2 that is
referenced.
>
> line 620 - reads: "OASIS SHALL NOT guarantee any specific lifetime
> to URNs in those test spaces for the TCs." which flies in the
> face of the whole concept of a URN. Quoting from RFC2141 [2]:
> "Uniform Resource Names (URNs)
are intended to serve as persistent,
> location-independent, resource identifiers."
> Thus, the specific lifetime of a URN is FOREVER. Period. Anything
> else is an abomination of the whole concept of a URN, regardless
> of its purpose.
>
> line 641-685 - The WS-RX TC ran headlong into a problem with the
> http://docs.oasis-open.org/[product]
> convention because the WSRM TC objected. Seems that because the
WSRM
> TC has a shortname
> that is the same as the productName assigned by the OASIS Staff
for
> the WS-ReliableMessaging
> specification, that they thought that there might be confusion
> (sigh). Thus, we had to
> assign namespaces that were of the form: http://docs.oasis-open.
> org/ws-rx/[product]/...
>
> So, I think that given that there is a normative requirement in
the
ASIS that
> directly conflicts with what we HAD to do per the OASIS staff that
it might be
> better to enforce a rule that required that everything be in the
form:
> http://docs.oasis-open.org/[tcshortName]/[product]/...
>
> Also, we chose to use a date for the "[productVersion]"
rather than
> what is prescribed in the ASIS because we did not want to have the
> namespace bound unnecessarily to the version of a specification.
Youwill
note
> the OASIS WSS 1.1 preserved the namespace from 1.0 for many of the
> specified components so as to preserve backwards compatibility.
>
> This is an important point, and IMO the WSS TC did exactly the
right
> thing. However, it would seem to me that a reading of the current
draft of the
> ASIS might be interpreted as making that a clear violation of the
ASIS policy
> guidelines (that will become mandatory).
>
> [1] http://www.oasis-open.org/committees/download.
>
php/16546/ArtifactStandardIdentificationSchemeForMetadata-1.0.1.pdf
> [2] http://www.faqs.org/rfcs/rfc2141.html
> [3] http://microformats.org/
>
> 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
>
> James Bryce Clark <jamie.clark@oasis-open.org> wrote on
02/06/2006
> 02:44:36 PM:
>
> > OASIS Members:
> >
> > The OASIS Technical Advisory Board (TAB) has asked that the
OASIS
> > membership and the public review its
> >
> > OASIS Artifact Standard Identification Scheme
for Metadata
> >
> > and provide comments during the period ending 1 March 2006
(details
below).
> >
> > This document, approved by the TAB, proposes rules for how
OASIS
artifacts
> > (e.g. specifications, schemas, WSDL) are named, what metadata
must be
> > associated with each artifact, consistent filenames and
persistent
(and
> > consistent) URIs for artifacts (incorporating some of the
required
> > metadata), and updates to the OASIS URN spaces.
> >
> > This work furthers goals for consistent naming, persistent
URIs,
and the
> > efficiency of data and document management across OASIS. Many
of the
> > recommendations are already in effect, e.g. in the current
document
> > templates. Others are guidance for work in progress, e.g.
persistent
URIs
> > for accessing OASIS artifacts.
> >
> > Please carefully consider the proposed requirements, as their
> > implementation will facilitate pending improvements in OASIS
document
> > management, process automation, and expression of namespaces.
> >
> > While this document is written as a set of requirements, the
use of this
> > document is recommended and not mandated. After this second
General
> > Membership review in February 2006, we expect that the OASIS
Technical
> > Advisory Board will approve a future version as a
contribution
to ongoing
> > OASIS policy discussions.
> >
> > Earlier versions of this document, under various names, have
been
> > circulated to the OASIS Chairs email list and (as the
"Artifact
> > Identification Requirements") went through a General
Membership
Review
> > cycle in July 2005.
> >
> > The package for this General Membership Review includes
> >
> > (1) This cover letter
> >
> > (2) The document
> > ArtifactStandardIdentificationSchemeForMetadata-v1.0.1.pdf:
at
> > http://www.oasis-open.org/committees/download.
> >
php/16546/ArtifactStandardIdentificationSchemeForMetadata-1.0.1.pdf
> >
> > (3) A spreadsheet listing comments and responses from the
July
2005
> > review: at:
> > http://www.oasis-open.org/committees/download.
> >
php/16547/ArtifactStandardIdentificationSchemeForMetadata%20Public%
> > 20Review%20Resolutions.pdf
> >
> > Discussion will take place, and comments will be taken from,
the
> > oasis-member-discuss list; to send to that list and to
receive
real-time
> > emails, please apply to join the list(login as a member,
select
All Groups,
> > scroll down to OASIS Member Discuss, and click the "Join
Group" link. There
> > is no waiting period.
> >
> > Comments will be considered through those received on March
1,
2006,
> > midnight US Eastern Standard Time.
> >
> > Thank you for your consideration of these important issues.
> >
> > The OASIS TAB
> >
> >
> >
---------------------------------------------------------------------
> > This email list is used solely by OASIS for official
consortium
> > communications. Opt-out requests may be sent to
> > member_services@oasis-open.org, however, all members are
strongly
> > encouraged to maintain a subscription to this list.
> >
|