URNs (issue a.3)

[jon.bosak@sun.com]

Hello UBL TC,

Gunther Stuhec has noted [1] that the namespace URNs in the UBL
1.0 CD "are not based on the namespace rules of chapter 3.4.2
(Namespace Uniform Resource Identifiers)", specifically NDR NMS5,
which reads as follows:

   [NMS5] The namespace names for UBL Schemas holding OASIS
   Standard status MUST be of the form:

      urn:oasis:names:specification:ubl:schema:<name>:<major>:<minor>

Eduardo Gutentag has pointed out [2] that URNs used in OASIS
specifications must follow Internet RFC 3121, which defines the
OASIS URN namespace [3], and has proposed an alternative that
would set the pattern not just for UBL but for all OASIS standard
schemas (yes, we are once again breaking new ground here).  I will
not copy Eduardo's proposal here (the message referenced at [2]
can be found in mail sent to the TC 26 July 2004), but the essence
of it is summarized in the following examples:

   urn:oasis:names:specificaton:ubl1.0:schema:xsd:CoreComponentParameters1.0
   urn:oasis:names:specificaton:ubl1.0:schema:xsd:AcknowledgementResponseCode1.0
   urn:oasis:names:specificaton:ubl1.1:schema:xsd:CoreComponentParameters1.0
   urn:oasis:names:specificaton:ubl2.0:schema:xsd:AcknowledgementResponseCode1.5

Note in particular the last one, which illustrates the
independence of UBL version number and schema version number.

In today's Atlantic UBL TC call, we discussed Eduardo's proposal
and came to the following conclusions:

 - We agree that RFC 3121 takes precedence over the current NMS5.
   This means that we will indeed have to change all the namespace
   URNs.  We don't think that we will have to change any of the
   file names.

 - We agree to accept Eduardo's proposal with the following
   provisos:

    - We can't just delete the existing NMS5.  We need to replace
      it with a new rule specifying the RFC 3121-compliant way in
      which we are forming the UBL namespace URNs.

    - We don't see why we need to include a version number in the
      specification-id field (the one that has "ubl1.0" in
      Eduardo's examples).  We understand that RFC 3121 allows
      this, but we don't believe that RFC 3121 requires it, and we
      can think of cases where including the version number would
      not be helpful.

      Suppose, for example, that an imaginary UBL 2.0 release
      includes an imaginary AcknowledgementResponseCode1.5 schema
      identical to the schema that originally shipped with the
      imaginary UBL 1.5 (as in Eduardo's fourth example URN
      above).  Keeping the 1.5 version of the schema is presumably
      a good thing because UBL 1.5 code written to process
      instances conforming to that schema will continue to work,
      but that won't happen if the namespace URN is changed; in
      that case, updating the specification-id from "ubl1.5" to
      "ubl2.0" will have an effect opposite the effect presumably
      intended in keeping "AcknowledgementResponseCode1.5" as the
      document-id.

      So we concluded (almost but not quite unanimously) that we
      would prefer to use "ubl" for the specification-id and let
      the versioning of individual schemas be conveyed by the
      document-id.  (The counterargument was that including the
      UBL version number in specification-id would indicate that
      the 1.5 schema was re-released as part of UBL 2.0, but (a)
      the URN is the wrong place to be looking for packaging
      information, (b) we may find (as apparently X12 did) that we
      don't want to tie module revisions to major releases, and
      (c) including "2.0" wouldn't tell us anything about the
      package structures of releases 1.5 through 1.9, if any.  In
      sum: the software won't care what release the schema came
      from, it will only care that this is still the same old
      schema it knows and loves.)

In keeping with the agreement to adopt a new rule before we can
regenerate the schemas, therefore, and in the absence of anyone
else available to do it this week, the participants tasked yours
truly with the job of proposing to the TC a replacement for NDR
NMS5 today.  They also noted that NMS4 and NMS6 would have to be
looked at, too.  The current versions read as follows:

   [NMS4] The namespace names for UBL Schemas holding committee
   draft status MUST be of the form:

      urn:oasis:names:tc:ubl:schema:<name>:<major>:<minor>[<revision>]

   Note:

      [ ] = optional. 

      <> = variable


   [NMS6] UBL Schema modules MUST be hosted under the UBL
   committee directory:

      http://www.oasis-open.org/committees/ubl/schema/<schema-mod-name>.xsd

It seems to me (and I am ready to stand corrected!) that we do
need to revise NMS4 along with NMS5 this week, but I don't see any
need to change NMS6.  I will note that a functioning URN resolver
should make NMS6 unnecessary, but if we have to have a canonical
location (and in the short term we probably do), then I think that
this one will work as well as any.  I also note that its implicit
reliance on the document-id alone is in keeping with the point
made above on this subject.

Appended to this message are my proposed replacements for NMS4 and
NMS5.  Since time is of the essence, please make any comments
within the next 48 hours; whatever we seem to have agreed upon by
Friday my time in Orlando is what I will propose that we adopt for
the schemas to be approved in Copenhagen.  Anyone available this
evening, or this morning, depending on where you are, should note
that the Pacific TC call coming up in about 1.5 hours would be a
great place in which to discuss this.

NOTE that these revisions will also necessitate revision to the
versioning rules in section 3.5 of NDR, but I *think* that those
revisions can be accomplished simply by substituting periods for
colons in the part of the URN that we are now calling
"document-id" (which means that the document-ids we end up with
won't look exactly like Eduardo's examples but more like
AcknowledgementResponseCode.1.5).  It would be very helpful if
someone could attempt this revision and tell us whether it's that
easy before I put the whole question to you on Friday.  If I have
to make the revisions to 3.5 myself, it could get ugly....

Jon

[1] http://lists.oasis-open.org/archives/ubl-comment/200406/msg00004.html

[2] http://lists.oasis-open.org/archives/ubl/200407/msg00082.html

[3] http://www.faqs.org/rfcs/rfc3121.html

==================================================================

PROPOSED REPLACEMENT FOR NDR NMS4

   [NMS4] The namespace names for UBL W3C Schema drafts
   MUST be of the form

      urn:oasis:names:tc:ubl:schema:xsd:<document-id>

   where <document-id> is a unique identifier assigned to the
   schema by the UBL TC.  The document-id MUST follow the
   versioning scheme specified in section 3.5 and MUST NOT contain
   colons.  For Relax NG schemas, the sub-type field of the URN
   MUST contain "rng" instead of "xsd", and for ASN.1
   specifications, the sub-type field of the URN MUST contain
   "asn1" instead of "xsd".

   Note:

      [ ] = optional. 

      <> = variable

PROPOSED REPLACEMENT FOR NDR NMS5

   [NMS5] The namespace names for UBL schemas holding OASIS
   Standard status MUST be of the form specified in NMS4 for
   schema drafts, but with "specification" replacing "tc" in the
   fourth (document class identifier) field of the namespace URN.