UBL-UID [Was Re: [ubl-ndrsc] NDR SC Minutes April 2 2003]

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

Thanks Mavis for the minutes.

>>C: I think it is good to have an ID
>>E: I think it is good to have an ID attribute in some places but not in the
>>schema with a fixed value.

Just to add to some of the comment elaboration, I think Eduardo
meant that the UBL UID attribute gets stored in some places
but not in the document instances as that would mean all the
instances carry an extra load of fixed value information.
(Correct me if I didn't get that right, Eduardo).


UBL-UID
=======

I agree with Eduardo's comment, and I suspect that the UBL UIDs
weren't meant for that purpose as well.  The Document Instance
IDs that we're supposed to discuss but didn't get around to were
more for that purpose.  But we'll discuss that when we come around
to it.

I also would like to supplement the comment about being "good to
have an ID".  The reasons are:

(1) Provides a very specific reference to elements in the schema.
It may not seem absolutely necessary as we can describe elements
such as the Date field within the IssueDate element within the
Order schema of 0p70 etc, but having UBL UID to pin-point the
intended element is very handy and useful.  In fact, this is
how LCSC side relying on to refer to incoming comments.

(2) For developers, the IDs may provide a reliable point of 
reference (as long as the IDs are unique) to accelerate 
references, schema validation, and processing in general.
For debugging, error reports, etc, this is also useful.
Again, this might not seem absolutely necessary, but perhaps
a very nice to have.

(3) Across UBL versions as UBL schema evolve from 1p00 to 2p00
and beyond, a uniqueness of UBL UID across versions will also
provide very handy and clear references to the "accounting" of
elements.  If we keep in mind the possibility that some
elements might get dropped and new ones might get added in
future, we can refer to these "disappearing" and "appearing"
elements in a clear manner.

For (3), it is very good to have consecutively running UIDs
across versions, so a UBL UID register can account for all
the UIDs across the entire versions (now and in future)
of UBL schemas.



Location of UBL-UID
====================

I'm not sure what's the reasoning to place this UBL UID meta
info into the XHTML documentation area, or if I have misunderstood
from the confcall.  If UBL UIDs are going to be used in (1)-(3)
listed above, a fixed location within the schema, as is done
in 0p70 release now, is almost a necessity.

If UBL UID gets into documentation area, the extra presentation
elements will first get in the way, and second, being a 
documentation area, it is meant more for human reading and
texts and XHTML elements can be arbitrarily added or removed.
I'm not sure how a UBL processor that looks for UBL UIDs for
hints can easily accomplish that when these UIDs become
moving targets in the sea of XHTML text and elements.




Best Regards,
Chin Chee-Kai
SoftML