We're going to need to decide the issues surrounding "code lists" very
soon. Mike's position paper is here:
http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-Rawlins-codelists-01.doc
Here are a few unorganized thoughts to get the discussion going; everyone,
please respond with your thoughts, and I'll try to formulate votable
questions as we go:
I think we may have more issues at stake here than just choosing
"enumerations of the xsd:string type" vs. "one element per code list
value". Here are some issues I can think of:
- 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?
- 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>
- 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.
- 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?
It would be great to see some of these additional issues spun out in the
next rev of the position paper.
Finally, regarding the "enumerations of the xsd:string type" vs. "one
element per code list value" choice itself, I'm not sure I buy the argument
that the latter is better. It could potentially swell the number of UBL
elements by orders of magnitude, and the infrastructure needed to document
and manage elements would seem to outweigh the benefits for these little
values.
Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ sun.com