Re: [oasis-member-discuss] Re: [members] Membership and Public Review ofOASIS Artifact Standard Identification Scheme for Metadata

[Christopher B Ferris <chrisfer@us.ibm.com>]

Bill,

As I have tried to make abundantly clear,
I think it folly to try to imbue the filename with
parsable metadata. Metadata should be
contained within the artifact (and machine processable
if possible, in addition to being human
readable) or be associated with the artifact
by some other means (such as I have
suggested in other missives).

As others have pointed out, forcing
filenames to be changed just because the
version/revision changes, or the status,
etc. will create more problems than
it is intended to solve.

That aside...

While I could live with the constraint
of not allowing hyphens in the filename save those
that are used as metadata separators,
I am fundamentally oposed to precluding their
use in the non-terminal path component
of a URI, especially given that the OASIS
persistent URI space has already violated
this constraint.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

William Cox <wtcox@comcast.net> wrote on 02/27/2006
10:00:28 PM:

> 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
OASISartifacts 
> > > (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.
> > >