Re: [ubl-ndrsc] Fw: [ubl-lcsc] ccts Annotation Structure (fwd)

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

On Mon, 30 Jun 2003, Eduardo Gutentag wrote:

>>Chin Chee-Kai wrote:
>>> It seems that the design of namespace values by itself is already
>>> not immutable over time with or without this discussion.
>>>
>>> The appending of version numbers to namespaces means namespace
>>> values will change in time, which is not good and does not help
>>> in migration phase from version changes.
>>
>>You seem to be implying that a namespace (for example, a namespace
>>for <Order>) should not change from version to version. 

There is advantage in doing that, especially for UBL processor
that handles incoming documents that the UBL processor cannot
know a-priori what type and version the black-box document
is so far.  Thus, from a schema-oriented UBL processor's point
of view, the UBL processor cannot determine which version
of which schema to apply, except perhaps to try every single
one on the incoming document, and hoping that one validation
occurs.  

The UBL processor could, of course, "cheat" by doing out-of-schema
pre-processing by peeping and reverse-engineering the namespace 
value just so to determine the type and version.  But this is 
exactly, in my view, the undesirable situation that this rule
forces UBL processors to do.




>>While I
>>am aware that this is one possible position regarding namespaces,
>>that is not the view of namespaces that has been adopted. The view
>>that has been adopted is that when something changes in a schema,
>>its version changes, and so does its namespace and its namespace name.

Yes, I'm also sure some debate and thoughts have been put in.
I just don't know if the design has taken the above situation
into consideration and how such a namespace value design
addresses and helps that.




>>Whether the namespace changes by virtue of changing  the
>>version-dependent part of the namespace name or by virtue of some
>>arbitrary change in that name is not as important as the fact that
>>it does change. In our case we have decided that it does change, and
>>that change manifests itself as a mirror of the version. 

Yes, I know it's a bit late to discuss this, and if there is
agreement on my suggestion, I'm likely to end up having much
work to do to re-tune some of the tools.  So I'm very happy
to just smooth-sail along what has been decided.  But I also
do know now that the rule is not going to help very much in
some situations, if it doesn't hurt.  Hopefully, the collective
decision done some time back has the better part of the wisdom.



>>I am not
>>sure I agree with you that this does not help in migration phase
>>from one version to another.

May I know which part you're not sure?  Could you perhaps
enlighten me how this namespace design applies to a scenario
with millions of contextualized UBL instances (therefore, 
may types of UBL document schemas) floating around, some 
having versions 1.0, 1.1, 1.3, 1.3.1, 2.0, etc?



Thanks.



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