OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[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