Title: RE: [ubl-ndrsc] Code lists: discussion kickoff
When I sent this the first time,
I did not see any comments, so am resubmitting to further the
discussion.
-----Original Message-----
From: CRAWFORD, Mark
[mailto:]
Sent: Thursday, January 31, 2002 11:46
AM
To:
Subject: RE:
[ubl-ndrsc] Code lists: discussion kickoff
Eve wrote -
> - Extensibility of "internal" UBL code lists: I'm not
> entirely up to speed on XSD in this regard, but
is it sufficient/allowed to allow
> extension
developers to derive a new type based on xsd:string that unions the
> original enumerated values with some new values
of their own?
> Would this do the trick for
us?
I think we need to discuss this aspect of extensibility which
I see different (albeit related) to the notion of adding elements. At
what point do extensions break the standard?
> - Ad hoc extensibility: Will
there be cases where it's
> acceptable/necessary to
have an escape hatch in the code list, in the CodedOther
> style? This was a common trick in the DTD-only days:
>
> <ice-cream
> flavor="other"
>
other-flavor="whatever-I-want">...</ice-cream>
Yuck! Sounds like the old "zz" - mutually defined from
X12. We probably do need a mechanism for this. Should these extensions
be the only codes that are enumerated in the schema?
> - Inclusion of external code
lists: Do these need to be
> dynamic somehow, and
if so, how should we handle this in the schema code? XSD
> never chose to solve this problem properly when
it was being designed, so
> the only thing I can
think of would be to use a string-based type and *not*
> constrain the values at all through the XSD layer. Checking
of values
> would have to be done as some higher
business-rules layer.
Should we just avoid enumerations of existing code lists -
including UBL created code lists? One way would be to create a standard
'CodeListIdentifier' tag and a predefined UBL data values for every entry in a
UBL 'list of code lists' external code list. We could then just convey
the code for a code list in one element and then identify the appropriate code
from that list in a paired element - a la EDI. We then avoid the whole
messy issue of ad nauseum enumerations within the schema, and leave dynamic
validation up to the Server. Of course we would still have to tackle the
issue of restrictions to external code lists.
> - Unique identification of code
lists: The SAML spec has a
> couple of cases where
it allows values from either its own internal code list or some
> external list in various places. It defines
its internal lists by
> attaching URIs to them, a
la XML namespaces. Should we do the same
>
thing? Should we define canonical URIs for common external
> "symbol spaces" if they don't already have
URIs?
