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

[Chin Chee-Kai <cheekai@softml.net>]

>>[cheekai@softml.net:]
>>
>>| 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.


On Wed, 18 Aug 2004 MCRAWFORD@lmi.org wrote:

>> The reason for the change centered
>> around the namespace scheme specified in RFC 3121.

I can see the reason for the change now.  It's good to catch
up on following RFC 3121.  However, introducing the use of "-"
as a special separator used for version separation is in
my opinion not a good choice.  It introduces ambiguity about
the precedence of ":" and "-", and precludes use of "-" as
part of the lexical space of document-id names.  In fact "document-id"
itself already requires use of "-" to describe itself.


>>  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.

RFC3121 does NOT say the "final" component is document-id;  all it 
says is that the document-id follows the optional {subtype} if present,
and otherwise follows the {type}.  


>> 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.

"Confusing" is a subjective and relative term.  For processing,
it is confusing when one introduces ambiguities in symbol precedences.
There's no confusion in using the same character to separate
"urn", "oasis", "names", etc, why should there be confusion in
this particular field following document-id?   The fixed separator
":" and the pre-defined, unambiguous relative positions are sufficient
to give clear meanings to each field involved.


>> 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.

This is good consideration for future compatibility.  But as I said,
RFC3121 does not say the "final" component must be document-id.
Indeed, in its section 3 examples, it gives a "tc" example that
has a version field following {document-id}, and most importantly,
it agrees with using the same ":" separator to demarcate the version
field:

RFC 3121: ---------------------------------------------------------
            ............
3. Examples

   The following examples are not guaranteed to be real.  They are
   listed for pedagogical reasons only.

      urn:oasis:names:specification:docbook:dtd:xml:4.1.2
      urn:oasis:names:tc:docbook:dtd:xml:docbook:5.0b1
      urn:oasis:names:technical:memo:9502:1995
      urn:oasis:member:A00024:x
            ............
-------------------------------------------------------------------

If we follow 3121, let's follow truthfully then.




Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/