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] Re: what to do about namespaces in schemas





On 07/19/2004 04:11 PM, Anne Hendry wrote:
> If this is dictated by rfc 3121, not by the TC, why do we need an NDR 
> for it?  

And Eduardo answered:

>We may not.

Not sure I agree.  When we talked about this in NDR, we felt that it was necessary to ensure consistency in how those components of the NSS not specified in 3121 are applied.  


Anne wrote:

> It seems at the moment we have an NDR that may conflict with 
> this rfc unless
> 
> these ubl ndr name components can be mapped to these rfc 3121 name 
> components:
> 
> 'ubl'  -> 'specification-id'
> 'schema' -> 'type'
> 'name' -> 'subtype'
> 'major:minor' -> 'document-id'
> 
> Even so, if Eduardo is correct about the need to make the document-id 
> 1.0 rather than 1:0 (which makes a lot of sense) then the rule is still 
> incorrect because of the ":" between major and minor. 

And Eduardo replied:

>I have a query out as regards how many colons we can have in the rightmost
>area where document-id is specified. We may have some leeway there, but it's
>not clear. Will let you know as soon as I know.

>In the meantime, it's obvious to me that 'ubl' does not map to 'specification-id'
>nor 'name' to 'subtype' (BTW, what do you mean 'name'? Do you mean 'names'? Or
>something else?

Since document-id is an OASIS contrivance, my presumption is there are no restrictions.  Eve (I think it was Eve but may have been Bill) developed the namespace scheme, they were very careful to  align with 3121.  Our logic in the rule still appears valid to me.

Anne wrote: 

>  Is there really a 
> need for an NDR for the entire URN?  The only part of such a rule that 
> would be needed is something to state which values UBL will use for 
> which components of the rfc 3121 urn that are *not* dictated by the rfc 

And Eduardo replied:

>correct

I would rather see a URN rule that provides the complete URN - both NID and NSS, than a fragment that may cause mistakes.

Anne wrote:

> (specification-id, type, subtype, documen-id).  Repeating the other  
> parts of the urn in the ndrs  seems to me to be redundant and a  source 
> for problems .

And Eduardo replied:

>Agreed. In fact, I'm not sure that there is a need  at all for an NDR rule
>that says how to do things that are OASIS specific...>

Same comment as above.  We discussed this in NDR and felt strongly that there is a need for this rule.

>As to what we've been using until now, I'm afraid I can't make heads or
>tails of things like
>xmlns:cac="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0"
>xmlns:res="urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0"
>What is 'codelist' suppposed to be in the above?

Reviewing both 3121 and the NDR I am still convinced that we have it right.  3121 calls for the following for schema:

urn:oasis:names:specification:{specification-id}:{type}{:subtype}?:{document-id}

our rule for schema holding specification (as opposed to TC draft) states:

urn:oasis:names:specification:ubl:schema:<name>:<major>:<minor>

I believe that 
	1. "ubl" equates to specification-id
	2. "schema" equates to {type}

I further believe that <name>:<major>:<minor> equate to {document-id}.

Mark



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