OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl] URN Proposal


Ugh, that text attachement is not very nice, is it? I'm attaching an HTML
version instead...

On 07/26/2004 02:11 PM, Eduardo Gutentag wrote:
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> OASIS URN Construction and the Use of URNs in UBL's namespaces:
> 
> 
[...]
> 
> 
> ------------------------------------------------------------------------
> 
> 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

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

xsd1

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.

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

1There 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)


2Use dot as a separator between major and minor. Do not use a separator between major.minor and what precedes it.



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