OASIS Universal Business Language (UBL) TC

 View Only
  • 1.  URN Proposal

    Posted 07-26-2004 21:12
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ubl message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: URN Proposal


    I'd like the UBL TC to consider the following proposal on how to deal with URNs,
    how to modify existing URNs for the upcoming OASIS Standard UBL 1.0 document(s),
    and how to deal with NDR Rule NMS5.
    
    Unfortunately, I will not be present at this Wednesday discussion, but I hope what
    I'm sending is detailed enough.
    
    Attachements: a text version and an OpenOffice version. Thanks.
    
    I'm cc'ing Karl Best because with just a few modifications part of this write-up
    can be used for OASIS general purposes.
    
    -- 
    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
    
    OASIS URN Construction and the Use of URNs in UBL's namespaces:
    
    The issue:
    UBL uses URNs to construct namespace names. OASIS has a URN space by itself, and the specification of that URN space is to be found in RFC 3121 (http://www.faqs.org/rfcs/rfc3121.html)
    According to RFC 3121, the format for an OASIS URN is:
    urn:oasis:names:specification:{specification-id}:{type}{:subtype}?: {document-id}
    The issue is whether current namespaces are properly constructed and whether the current NDR rule for URL construction is either needed or correct.
    Current UBL construction of URNs:
    The current construction of URNs for UBL namespaces is regulated by NDR Rule NMS5, which says: 
    The namespace names for UBL Schemas holding OASIS Standard status MUST be of the form:
    	urn:oasis:names:specification:ubl:schema:<name>:<major>:<minor>
    The are three questions related to this:
    1.Does this rule reflect RFC 3121 accurately?
    2.Does the current URN construction follow this rule?
    3.If not, is the current URN construction correct or should it be modified?
    
    Does this rule reflect RFC 3121 accurately?
    If the number of fields in the format specified in RFC 3121 were fixed, then there would be no problem in having colons be part of document-id; however , because the number of fields is indeterminate due to the presence of the optional subtype  field, this should not be allowed. In other words, given the presence of optional fields, a construction of the form:
    	urn:oasis:names:specification:ubl:schema:a:b:c:d:e:f
    is too ambiguous, as it is impossible to determine whether document-id starts at a or at b. Therefore, colons should not be used within document-id, and the rule does not reflect RFC 3121 accurately.
    
    Does the current URN construction follow this rule?
    The current URN constructs are of the forms:
    urn:oasis:names:tc:ubl:Order:1:0
    urn:oasis:names:tc:ubl:CoreComponentParameters:1:0
    urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0
    Apart from the use of tc instead of specification, due to the status of the documents at the time these namespaces were constructed, it would seem that these namespaces do adhere to the rule; however, close inspection reveals that even allowing for the change from tc to specification, these namespaces do not conform to the rule because the schema field is never used.
    
    If not, is the current URN construction correct or should it be modified?
    Apart from the use of tc instead of specification, due to the status of the documents at the time these namespaces were constructed, it would seem that these namespaces do not adhere to RFC 3121 either, as type-subtype is sometimes specified (e.g. codelist), sometimes not, and major:minor includes a colon as part of document-id.
    
    Proposed  UBL Construction of URNs:
    RFC Field                                      UBL Field
    urn                                            urn
    oasis                                          oasis
    names                                          names
    specification                                  specification
    specification-id                               ubl1.0
    type                                           schema
    sub-type                                       xsd[1]
    document-id                                    CoreComponentParameters1.0, 
                                                   CommonAggregateComponents1.0, 
    											   AcknowledgementResponseCode1.0, 
    											   etc.[2]
    
    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
    
    URNs referring to RelaxNG equivalents would of course replace xsd with RelaxNG.
    Note the interplay between Specification version and schema version.
    
    [1] There is no room in RFC 3121 at this time to specify a sub-type as a codelist, etc. A sub-type is defined as additional information about the document type (for example, stylesheet or schema language)
    [2]Use dot as a separator between major and minor. Do not use a separator between major.minor and what precedes it. 
    
    Is NDR Rule NMS5 needed?
    Given that RFC 3121 is somewhat ambiguous regarding the inclusion of colons in the last field of the OASIS URN (ambiguous only in the sense that it does not explicitly prohibit the inclusion of field separators in one of its fields), it could be argued that there is a need for a rule that at the very least deals with the document-id field.
    On the other hand, given that this is an OASIS issue, and not just a UBL one, I would propose that this NDR Rule be deleted, or that it be replaced by a rule that says "The construction of URNs for OASIS objects is specified in RFC 3121; follow OASIS instructions on how to adhere to this RFC", and that we provide OASIS with the right input (which I intend to do anyway). 
    Alternatively (but I really don't like this), Rule NMS5 should be replaced by a very detailed description of how to construct a URN, followed by Rule NMS6 that would say "Rule NMS5 will become superseded by whatever instructions OASIS issues on how to construct OASIS URNs."
    

    ubl-gutentag-urns-0.1.sxw



    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]