Re: URNs (issue a.3)

[jon.bosak@sun.com]

Hello UBL TC,

This will be my last message on the subject of URNs for a few
days.  So far the only response I've gotten to yesterday's and
Wednesday's draft proposals are a couple of comments from Eduardo
Gutentag, who is himself disappearing from view today and won't be
back in contact until we see him in Copenhagen. I'll get to those
comments in a second.

It seems to me that there are four possibly controversial aspects
of the plan I suggested yesterday (which was in turn based on
Eduardo's recent proposal supplemented by this week's Atlantic and
Pacific TC calls): (1) the use of "ubl" rather than "ubl1.0" in
the RFC 3121 specification-id field of URNs referring to the OASIS
Standard version of UBL; (2) the difference between the proposed
values for the RFC 3121 subtype field and what I called the
"filetype" field; (3) the substitution of the "Foo-1.0" form of
document-id for the previous "Foo:1:0" form; and (4) the
abandonment of absolute URLs in the revision of ATD5.

I want to draw your attention to these potential issues so that we
don't adopt these suggestions without being aware of their
implications.

1. The specification-id field

   In drafts (which have "tc" in the fourth or "document class
   identifier" field of the OASIS URN), "ubl" is required in the
   fifth ("tc-id") field because that field contains the name of
   the TC.  Regarding OASIS Standards (which have "specification"
   in the document class identifier field of the URN), RFC 3121
   says:

      The general structure of the NSS in the specification
      hierarchy has the form:

         urn:oasis:names:specification:{specification-id}
                           :{type}{:subtype}?:{document-id}

      where "specification-id" is a unique identifier for the
      specification, "type" identifies the document type
      (document, schema, stylesheet, entity, xmlns, etc.), the
      optional "subtype" provides additional information about the
      document type (for example, stylesheet or schema language),
      and "document-id" is a unique identifier for the document.

      The Director of Technical Operations at OASIS assigns
      document types, subtypes, and all unique identifiers.

   It appears from this that we can put just about anything we
   want in "specification-id" as long as OASIS agrees with our
   choice.  I think that this field should contain "ubl" rather
   than "ubl1.0" because (a) I want to minimize the change in URNs
   going from drafts to Standards and (b) I don't want to wire in
   a dependency between UBL releases and versions of the
   individual schema modules.  But Eduardo disagrees:

      Regarding NMS4 and 5:

      No problem with NMS4, but when NMS5 tries to parallel NMS4
      and simply says that specification-id must be "ubl", I think
      this may be incorrect (but this is in a way dependent on
      what the TC wants to do here.) specification-id will
      probably be indeed "ubl" in many cases because this is
      indeed a specification of UBL, the output of the UBL TC. But
      what happens when the output of the UBL TC is, let's say,
      NDR? Why not say that specification-id in that case is
      "ndr"?

   I think that my answer to this would be, "All the more reason
   to make the specification-id field just contain 'ubl', because
   'ndr' in that place would imply that these are naming and
   design rules for *all* OASIS schemas, not just UBL schemas."
   But others may disagree.  We could always put in longer and
   more descriptive identifiers (like "ubl-ndr").  People need to
   think about this.

2. The subtype and "filetype" fields

   My proposed revision to NMS6 says:

      [NMS6] UBL Schema modules MUST be hosted under the OASIS UBL
         Technical Committee directory at the URL

         http://www.oasis-open.org/committees/ubl/schema/<subtype>/UBL-<document-id>.<filetype>

      where <document-id> follows the UBL rules for UBL RFC 3121
      document-ids, <subtype> refers to a token specifying the
      schema language (currently one of "xsd", "rng", and "asn1"),
      and <filetype> refers to the file format ("xsd", "rng",
      "html", etc.) used to store the schema at that location.

   Eduardo asks:

      Question regarding NMS6: it says that <filetype> may be one
      of "xsd", "rng", "html".  This does not seem consistent with
      <subtype> being "xsd", "rng", and "asn1" nor is it clear to
      me when the filetype would be "html" if the filetype always
      refers to a schema language. Are you sure that <filetype>
      should not be one of "xml" or "html"?

   All I'm doing in the proposed revison of NMS6 is trying to
   accommodate the fact that the two kinds of schemas we've got in
   the 1.0 package are XSD schemas (for which the subtype would
   have to be "xsd") that have file names ending in ".xsd" and an
   ASN.1 spec (for which the subtype would have to be something
   like the proposed "asn1") that has a file name ending in
   ".html".  If anyone sees a better way to word this, please feel
   free to suggest it.  Also, if this conflicts in any way with
   the practice we seem to have adopted for schema file names,
   please alert us to the difference.

3. The form "Foo-1.0" versus the form "Foo:1:0"

   The change I'm proposing here is fairly radical given the two
   years of practice we've had using the all-colon form, and I
   certainly wouldn't suggest it if we weren't being forced to
   revise all the URNs anyway.  My reasons for preferring the
   "Foo-1.0" form are:

   a. It distinguishes the part we get to specify (the
      document-id) from the part we inherit from RFC 3121.

   b. It resembles the way this piece ends up in the filenames.

   c. We apparently adopted a checklist rule for codelist schemas
      in the 1.0 CD that used periods instead of colons, though
      this rule appears not to have actually been implemented.

   But again, there could be good reasons for keeping the
   all-colon form.  The fact that no one who proposed the
   all-colon form is either resisting this change or endorsing it
   makes me nervous, because it implies that no one is actually
   paying attention.  These need to be conscious decisions.

4. The abandonment of absolute URLs in xsd:schemaLocation

   I gave what I thought were good reasons for this in yesterday's
   proposal (mainly because (a) we are already providing an
   absolute schema location in NMS6 and (b) people will have to
   put system-dependent URLs in all of the xsd:schemaLocation
   attributes anyway if we don't give them relative URLs by
   default), but the absence of any responses, positive or
   negative, makes me nervous about this item, too.

Below you see yesterday's proposals with one correction (noted
yesterday) included.  Please take some time to think through the
implications of these proposals and send mail to the list if you
see anything that needs further discussion, and please do engage
in that discussion while I'm absent this week.  If at the end of
the week we seem to be in substantial agreement either with the
proposals as given or with some revision that people seem clearly
to prefer, I will take that as consensus.  If someone raises an
objection and the issue is still up in the air by the time we get
to Copenhagen, I've reserved a slot in the recently revised agenda
for further discussion on Monday, right after lunch.  We can't do
the packaging until we generate the final schemas, and we can't do
that until this is decided.

Jon

##################################################################

PROPOSED REVISIONS TO CHECKLIST RULES RELATING TO URNS, SCHEMA
NAMES, AND SCHEMA LOCATIONS

[NMS4] The namespace names for UBL schema drafts MUST adhere to
   RFC 3121 and MUST be of the form

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

   where <document-id> is a unique identifier assigned to the
   schema by the UBL TC and <subtype> is one of a list of values
   currently consisting of "xsd" for W3C XML Schemas, "rng" for
   Relax NG schemas, and "asn1" for ASN.1 specifications.

      [Note to the TC: "ubl" rather than "ubl1.0" is required in
      this case by RFC 3121, because this field (called "tc-id")
      in a document having an RFC 3121 document class identifier
      of "tc" is required to contain the name of the TC itself.]

[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.

[VER1] Every UBL schema and schema module major version draft MUST
   have an RFC 3121 document-id of the form

      <name>-<major>.0[.<revision>]

[VER2] Every UBL schema and schema module major version OASIS
   Standard MUST have an RFC 3121 document-id of the form

      <name>-<major>.0

[VER3] Every minor version release of a UBL schema or schema
   module draft MUST have an RFC 3121 document-id of the form

      <name>-<major-number>.<non-zero>[.<revision>]

[VER4] Every minor version release of a UBL schema or schema
   module OASIS Standard MUST have an RFC 3121 document-id of the
   form

      <name>-<major-number>.<non-zero>

[CDLX] (delete)

[CDLXX] (delete)

[CDLXXX] (delete)

[NMS6] UBL Schema modules MUST be hosted under the OASIS UBL
   Technical Committee directory at the URL

      http://www.oasis-open.org/committees/ubl/schema/<subtype>/UBL-<document-id>.<filetype>

   where <document-id> follows the UBL rules for UBL RFC 3121
   document-ids, <subtype> refers to a token specifying the schema
   language (currently one of "xsd", "rng", and "asn1"), and
   <filetype> refers to the file format ("xsd", "rng", "html",
   etc.) used to store the schema at that location.

[ATD5] Each xsd:schemaLocation attribute declaration MUST contain
   a system-resolvable URL, which at the time of release from
   OASIS shall be a relative URL referencing the location of the
   schema or schema module in the release package.

[ATD6] (delete)