MHonArc v2.5.0b2 -->
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
From: Eduardo Gutentag <>
To:
Date: Mon, 19 Jul 2004 16:17:50 -0700
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?
We may not.
> 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.
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?
> 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
correct
> (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 .
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...
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?
>
> -A
>
>
> :{type}{:subtype}?:{document-id}
>
>
>
> Also
>
> -A
>
> Eduardo Gutentag wrote:
>
>>
>>
>> On 07/19/2004 01:19 PM, wrote:
>>
>>> The committee drafts are just that- drafts. Specification is reserved
>>> for those that complete the oasis process.
>>
>>
>>
>> If we are talking about *the* document that will be presented for OASIS
>> membership approval as an OASIS Standard, then it has to follow the
>> naming rules contained in RFC 3121
>> (http://www.rfc-archive.org/getrfc.php?rfc=3121)
>>
>> I thought we were talking about *the* document. I've also just gone and
>> re-read the RFC, which I should have done to begin with...
>>
>> The URN should be:
>>
>> urn:oasis:names:specification:<specification-id>:schema:xsd:1.0
>>
>> Note that <specification-id> should be provided by OASIS. I certainly
>> believe that "ubl" is appropriate, but we should make sure that Karl
>> Best is aware of this and approves of it as specification-id; I may
>> be rehashing things...
>>
>> Note that OASIS (Karl) should assign type and subtype, but I believe
>> using schema:xsd should not be a problem.
>>
>> Note that it should say "1.0", not "1:0", I believe (although
>> the RFC could be read as saying that <document-id> [which is what
>> this would be] should be provided by OASIS too.)
>>
>> Sorry if this introduces even more confusion.
>>
>> If we are not talking about *the* document then the urgency of
>> getting it right decreases, even though it would indeed be nice
>> getting it right.
>>
>>
>>> Mark R. Crawford
>>> Senior Research Fellow - LMI XML Lead
>>> W3C Advisory Committee, OASIS, RosettaNet Representative
>>> Vice Chair - OASIS UBL TC & Chair Naming and Design Rules Subcommittee
>>> Chair - UN/CEFACT XML Syntax Working Group
>>> Editor - UN/CEFACT Core Components
>>> --
>>> LMI Government Consulting
>>> 2000 Corporate Ridge
>>> McLean, VA 22102-7805
>>> 703.917.7177 Phone
>>> 703.655.4810 Wireless
>>> The opportunity to make a difference has never been greater
>>> www.lmi.org
>>>
>>>