Namespace & versioning

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

Namespace
=========

I'm very happy with current namespace style in 0p70.  The thing
I'm happy about is that the namespaces of each Reusable and the
7 document classes are all different.  As all of you know that
XML specification only require the namespace values of different 
tagnames that carry different meanings to be *different*.

With that, I'm not exactly certain if encoding a lot of information,
such as the fact that it is an "Invoice" and not an "Order",
and that it belongs to version "0p70" and not "0p65", etc,
is a good or dangerous idea.  Unfortunately I cannot see what
"dangerous" effects such packing of info within the namespace
string have or will have at this point.  Perhaps that's the
reason why I'm waivering a little on this aspect.

The current namespace values in the documents are good to maintain,
however, because the formula that churns them out make each
document class have different namespace string.  This is important.

One comment I read from the inputs that suggests making
all "Order", "OrderAcknowledgement (Simple)", "OrderAcknowlegement
(Complex)" have the same namespace is something I don't quite 
understand.  Maybe I don't quite understand the rational in the
NDR proposed recommendation on namespace naming as well.  
The way it goes, it seems like if a doc class is prefixed
with "Order", it would have to use the "Order" namespace.
This seems strange to me as "Order" and "OrderAcknowledgement"
are documents used by different parties (in fact, exactly
opposing ends of the business communication).  I'm not sure why
(and it doesn't seem to come out from the NDR paper) we're 
aligning the namespace dimension with prefixes, instead of
more ground/end-user oriented factors  such as the fact that
the different doc classes are processed by different validators
on different machines.

I'm inclined to suggest that the existing one-namespace-per-
document-class style be continued.  It's good, it's clear, and
it's distinctive.  I'm much less inclined to pack all information
from document type, version, and any other information into
the namespace string.


Version
=======

Version of UBL schema used, as well as the document type
(ie, whether this instance is a "Order", "Invoice", etc), ought
to be explicit, required, and stand on its own fields.

Imagine the world having UBL v1.0 documents floating around,
and now UBL v2.0 is just introduced and some systems are
generating them but not others.  Packing version info into
namespace will immediate cause many schema-based validators
to throw out v2.0 since that namespace isn't known to v1.0
validators.  It's not clear to me how we can have a smooth 
upgrading of systems, or gradual migration, or more importantly,
gradual degradation where only new, unknown tags in v2.0 are
flagged with errors on v1.0 validators.  By packing version
in namespace strings, we run a risk of disowning the very
flexibility of XML that allows new tags to be introduced
without upsetting existing defined tags.

Packing document type info into the namespace string likewise
force schema-based validators to "try" each and every possible
document class for namespace match before either concluding that
it has a positive match on namespace to validate, or after 
running out all possibilities, to conclude that the instance
is unknown.  There is no need to force the validators to 
explore a potentially huge unknown space of possible namespace
strings if an explicit attribute, such as 

	docType="Order"

is clearly described in the instance.

In short, it seems to me that docType and version are 
meta-info attributes that should be in the UBL space.

Looking from the recipient UBL processor point of view,
a document is unknown and cannot be processed meaningfully
until its version and document type are clear.  The receiving
UBL processor only can expect that it is a UBL document,
of any version of any doc type.  To extract these 2 pieces
of info, it'll have to "look" for the 2 pieces of attribute
in the so-called well-known namespace.  Thus we might need
the instance document to have:

<ublOrder:Order 
   ubl:version="1.0"
   ubl:docType="Order"
   xmlns:ublOrder="urn:oasis:names:tc:ubl:Order"
   xmlns:ubl="urn:oasis:names:tc:ubl">
   ...
</ublOrder:Order>

The well-known, version- and document-invariant namespace
being "urn:oasis:names:tc:ubl", for example.




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


On Mon, 28 Apr 2003, Mavis Cournane wrote:

>>The powerpoint of the Opening Sub Committee Reort for the Oasis UBL Naming
>>and Design Rules Sub Committeee is available on the Oasis UBL NDRSC webiste
>>at:
>>http://www.oasis-open.org/committees/download.php/1773/UBL%20Namingand%30Des
>>ignt%20Rules-Opening.ppt
>>This meeting will be going on all through this week, we plan on posting
>>minutes each night for the day's work.
>>
>>Regards
>>Mavis Cournane
>>Cognitran Ltd
>>Co-chair UBL NDR SC
>>
>>