[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Code lists: discussion kickoff
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC