[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Re: URNs (issue a.3)
A clarification:
the only thing on which I have a v. strong opinion among those mentioned
by Jon is definitely the issue of colons in {document-id}. It would
be a grave error, I believe, to preserve the colons there for the
reasons I've already indicated (namely the optionality of {subtype}),
and OASIS practice will probably indicate in the future that colons
are prohibited there.
Thanks Jon for putting this all together in such a clear manner.
Jon.Bosak@Sun.COM wrote:
> 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)
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>
--
Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards | Phone: +1 510 550 4616 x31442
Sun Microsystems Inc. | W3C AC Rep / OASIS BoD
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]