RE: [ubl] Code list schema

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

> 
> | I would suggest that for the moment, UBL should just use 
> the "simple 
> | code list" facilities of the format, and avoid the "derived 
> code list" 
> | facilities.  That is to say, take the whole Schema, but use 
> only what 
> | is required.  I'm keen for UBL & FpML to be using the same 
> code list 
> | Schema, rather than each using a different version, if possible.
> 
> Me too.  My worry is that one of the agencies we're going to 
> be relying on to use our standard code list schema for the 
> specificaton of their code lists will at some point release a 
> version that does use the derived code list facilities and 
> that a user of that version expecting to just plug in the new 
> release will find that the XSLT we provide suddenly doesn't 
> work with it.
> 
> If it's possible to rig the XSLT so that it produces the same 
> Schematron assertion in the second case as in the first (by 
> simply ignoring the extra stuff), then I guess we're OK.

It strikes me that this path we are on for code lists is creating
dependencies that we should be avoiding.  I think we should step back
and revisit our requirements as it appears to me we are creating a
solution in search of a problem.  The original issue was how do we avoid
enumerations in our schema.  More specifically, how do we avoid
enumerations of code and identifier lists that someone else has
ownership of.  Our original solution was simple (and simplistic in
keeping with our original guiding principles)  - avoid enumerations,
generate a code list schema for those code lists we created, try and get
code list owners to generate a similar schema, and if necessary generate
code list schema for external code lists if the code list owner wouldn't
do it.  We are now bogged down into first/second pass validations,
schematron vs XSD, wildcards, substitution groups, and a plethora of
other rat holes that are taking us very far a field from the original
issue.  From my perspective, if we can't provide a simple code list
schema template for others to use, then we probably should just avoid
the whole code list issue and leave it up to implementers how they wish
to deal with it.  

I am also concerned that we will create a very complex solution for UBL
2.0 only to see it abandoned for UBL 3.0 by CEFACT.

Mark