[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: URNs (issue a.3)
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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]