Re: [ubl] Re: what to do about namespaces in schemas

[Anne Hendry <anne.hendry@sun.com>]

MCRAWFORD@lmi.org wrote:

>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.  Mark responded:
>
>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. 
>
The thing is that rfc 3121 does specify the components.  It just allows 
the last 4 components to have tc-specific values (as clearly indicated 
by the parens around those last 4 component names in the rfc) and I 
assume that's what you mean when you say '... those components of the 
NSS not specified in 3121 ...'.

But when you say you felt is was necessary to define a rule for "... 
those components ... not specified ..." your statement doesn't support 
specifying the rest of the components values that are dictated by rfc 
3121 (urn:oasis:names:[specification|tc|technical]) and whose values 
cannot be substituted/changed by UBL.

>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 
>>
>>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.
>
>I would rather see a URN rule that provides the complete URN - both NID and NSS, than a fragment that may cause mistakes.
>
My view is that it doesn't reduce mistakes - it increases the chance of 
them by confusing which body actually controls the full structure of the 
URN and by creating a maintenance problem, as you must track any changes 
to that rfc in areas that are beyond the purview of the tc and then 
update ndrs accordingly.  I would rather see a reference to rfc 3121 
which will clarify its structure for the use of the both the 'constants' 
(components whose values we don't have control over) and the 'variables' 
(the ones we provide our own values for), and then just have a rule(s) 
for the variables.  This makes it very clear what we are providing (and 
also allows the ndrs to address each of those 4 components more fully). 
 Including the entire urn in your rule implies ndr has some control of 
the entire thing, which it clearly doesn't.

>>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}.
>
Yes, that makes sense to me, with one exception:  if you say that all 
three name/major/minor are document-id, then what happened to 'subtype'? 
 Your rule then seems to ignore sub-type.  Did you not think it 
necessary?  I think we need 'subtype' - I originally thought it was what 
you specified in the rule as <name>, but now that you say <name> is part 
of 'document-id' we're lacking 'subtype'.   FYI, I believe that is what 
the 'codelist' entry is above.  

A main shortcoming of the rule is that it doesn't give any indication 
which of the specified values map to the urn structure specified in the 
rfc.   If you believe the rule should show the entire urn, then it's my 
view that you would have to duplicate most of rfc 3121 in order to 
explain the rule, which doesn't seem reasonable.  I still believe we 
should just site the rfc so that people can understand from where most 
of this string orginates and then say what values we are stipulating for 
the four items in parens in the rfc and include the explanation of which 
of our values map to which of the rfc components.

Regarding the use of '.' rather than ':' as the major/minor separator, 
the OASIS file naming conventions specify how to construct a string for 
file names using major/minor/revision, etc which uses a dot rather than 
a colon.  Now, I know this is a bit different, as it is for files rather 
than specs, but looking at a recent SAML publication, it uses the string 
'urn:oasis:names:tc:SAML:1.0:protocol' for one of the namespace urns, 
and that clearly has a dot for the major/minor reparator.  I assume this 
is a convention, but don't have time to go digging through more specs.  
I assumed this was done when the rule was written?

Obviously there are several thing needed here, and this is what I think 
we should do:

1.  Get a defnitive answer from OASIS on whether there are any 
conventions they want us to use for the 'variable' values in the urn string.
2. Review this and agree to a mapping of our urn to the rfc urn string 
(I can't believe we're having to do this now, but without some 
documentation of the mapping there's not enough info for anyone to make 
sense of this).
3. Agree on what values can be used for the four components we have some 
leeway with.
4. Review the urn namespace declarations, as right now the code list and 
common xsds appear to have incorrect namespace delcarations because some 
do not have the word 'schema', and some have sub-types and others not.
5. Decide what to fix and fix it.

-A