RE: [ubl-dev] Major namespace value structural change for a UBL 1.0-cd2?

[<MCRAWFORD@lmi.org>]

 Chin Chee-Kai,

Thank you very much for your input.

You wrote:

>The namespace value for CommonAggregateComponents schema in UBL 1.0-cd
(May 2004) is:

>"urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0"

>But for the UBL 1.0-cd (version 2), it has become:

"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-
1.0" 

>The change in namespace value structure seems to me very drastic for a
rather "tame" version upgrade from 1.0-cd to 1.0-cd2.
>(The same structural change is found in all the other schemas).
>Notably, the "tc" component has been changed to "specification", the
implied meaning of which throws me off into wondering what to expect >if
there's another cd3.

This has been the plan all along. See the NDR Section 3 Namespace for an
explanation.

>Also, "schema" and "xsd" together seems somewhat redundant, even
> if TC now wants to admit the possibility of future methods of
expressing
> schema (eg. relax-ng, etc).  With the presence of "schema" segment in 
>the namespace value, it sounds like there's possibility that UBL wants
to 
>standardize other aspects beyond schema (so the possible namespace 
>value could start with "urn:oasis:names:specification:ubl:xxxxx").  Is
that the intention?

This change is necessary to properly align the UBL namespace
declarations with RFC 3121 (See:  http://www.ietf.org/rfc/rfc3121.txt)

>Finally, the version segment representation has been changed from
":1:0" to "-1.0". 
 >I certainly hope such important demarcation characters will not be
casually altered
> from version to version, as this could cause major parsing difficulty
for applications 
.>that could break down namespace values for higher-level purposes.

After much discussion, the TC as a committee of the whole decided to
override the recommendation from the NDR regarding how we represent the
version component of the namespace.  The reason for the change centered
around the namespace scheme specified in RFC 3121.  That scheme
"urn:oasis:names:tc:{tc-id}:{type}{:subtype}?:{document-id}"  Calls for
the final component of the NSS component to be document identifier.  Up
until this point, we took the position that our document ID component
would be segmented by ":".  After careful consideration, we decided that
this was confusing and potentially dangerous.  Confusing because we were
using the same separator to segment a single component of the NSS that
was also being used to segment the components of the NSS.  Potentially
dangerous because if OASIS decides to change 3121 to add an additional
component at the end of the NSS piece of their namespace form, it will
result in collision with our segmenting of the document-id component.

 Mark
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