[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]