OASIS Member Discuss

 View Only

Re: [oasis-member-discuss] Membership and Public Review of OASISArtifact Standard Identification Scheme for Metadata

  • 1.  Re: [oasis-member-discuss] Membership and Public Review of OASISArtifact Standard Identification Scheme for Metadata

    Posted 02-28-2006 03:03
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    oasis-member-discuss message

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


    Subject: Re: [oasis-member-discuss] Membership and Public Review of OASISArtifact Standard Identification Scheme for Metadata


    Ian -
    
    Per my previous message to Chris Ferris, there aren't a lot of 
    punctuation characters available for URIs, and automated parsing is a 
    goal.  I'm sure that this issue will receive more attention.
    
    Ian Robinson wrote:
    
    >
    >
    >The WS-TX TC suspended consideration of transaction protocol messages for a
    >while today to discuss hyphens.
    >
    >We have an existing TC Root on the new document server being used for
    >predictable (and persistent) URIs:
    >      http://docs.oasis-open.org/ws-tx/
    >
    >The recommendation of the draft ASIS document is to use a TC tree root of
    >"wstx" rather than "ws-tx".
    >The TC decided that, given the draft status of the ASIS document,  we will
    >continue to use our existing root with the hyphen for now.
    >
    >The WS-TX TC requests the TAB to consider a change to the ASIS document
    >section. Currently, it states in section 8.2:
    >8.2 Technical Committee Tree
    >The short name of the OASIS technical committee, as established by the TC
    >Administrator, typically upon initial formation, MUST be the next node in
    >the URI after the base:
    >docs.oasis-open.org/[tcShortName]
    >
    >where, earlier in the document is a definition:
    >"The short name assigned by the TC Administrator to the Technical
    >Committee, with any hyphens eliminated."
    >
    >The WS-TX TC would like section 8.2 to remove the requiement to eliminate
    >any hyphen from the tcShortName that follows "docs.oasis-open.org/" in
    >persistent URI schemes.
    >
    >Regards,
    >Ian Robinson
    >STSM, WebSphere Messaging and Transactions Architect
    >IBM Hursley Lab, UK
    >ian_robinson@uk.ibm.com
    >
    >  
    >
    >>SNIP
    >>
    
    --- Begin Message ---
    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.
    > >
    --- End Message ---


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