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