In a message dated 3/11/2004 4:38:50 PM Eastern Standard Time,
jon.bosak@sun.com writes:
This looks to me like the same use case; the only difference
is
that the trigger for the creation of an expanded special-use
code
list came from IBM rather than BSI. You're going to go
through
the same committee meetings and the same software revision
to
implement this change that you would in my original
example.
I don't intend it to be the same use case. When IBM conspires with its
suppliers it is not working with BSI or UBL. It is a private activity to them.
We want them to be able to do this without assistance or permission from any
committee and, importantly, without altering
ubl or other base schemas.
So my question remains: how much work total have we saved
at the
expense of using a mechanism we explicitly ruled out for the
rest
of the specification?
I haven't seen the rationale they used for ruling it out, but I
would suggest that this can and should be a special case for code lists. It is
a problem unique to the extension of enumerated values that doesn't appear
elsewhere in XMLSchema to my knowledge. XMLSchema has other extension
mechanisms that apply to other cases.
If you are saying that this would allow valid UBL
instances to
include currency codes from alien namespaces without
changing the
namespace of the instance, I believe that we are all agreed
now
that this would be a bug, not a feature. If instances are
going
to be coming into my system that have unexpected currency
codes,
then I want those instances to carry a namespace that tells me
up
front that they have data structures that my system doesn't
know
how to handle.
I agree with your assessment here that this would be a bug. We want
all extensions clear, namespace qualified, and validate-able. It is not
possible to do this extension without a namespace change, and I think this is
what we want.
(Bear in mind that I am not an XSD guru, so if I'm
missing
something here, let me know.)
Jon
Hope this helps,
Marty