[ubl-ndrsc] New code list issues

["Eve L. Maler" <eve.maler@sun.com>]

Having described the code list recommendations to several people/groups 
over the last couple of weeks, I'm realizing that it has some features 
that we may want to rethink.  Does anyone have thoughts on the 
following?  If we agree to make code lists a high-priority item to 
polish in the next couple of months, we'll want to consider these:

*The need for attributes for the supplementary components

If we were to *require* a new namespace for each backwards-incompatible 
version of a code list schema module (while still requiring embedded 
documentation for its supplementary component values), in practice I 
don't know who's going to really make use of any fixed/default 
attributes on the inner code element containing the supplementary 
component information.  Developers will simply build support for that 
namespace and won't want to examine the attributes one by one.

So, for example, instead of this (where the attributes shown might be 
fixed, and thus don't have to appear in the instance but are still known 
to the parser and any downstream applications):

     <ISO3166CountryCode
       ID="3166"
       agencyID="ISO" ...>
     US
     </ISO3166CountryCode>

We'd just have this (where the knowledge that this element is of 
iso3166:CountryCodeType is all that matters):

     <ISO3166CountryCode>US</ISO3166CountryCode>

There are no attributes to trigger processing on, but you don't really 
need them because the element is still self-describing.  This would 
lower our "semantic clarity" score somewhat because the metadata isn't 
directly addressible by XML means; is that a problem in practice?  It 
would certainly simplify the guidelines we want code list agencies to 
follow.

*Whether to encourage/require foreign inner code elements

We still have our "local unqualified elements" decision on record, which 
is why we're mapping foreign code types to our own UBL-native inner code 
elements.  But our guiding principles do allow us to use foreign 
namespaces if we're careful, and I think it would be nice and clean to 
use <iso3166:CountryCode> if that's the element the UN/ECE folks offer 
the world.

So we'd have namespaced elements like this inside UBL:

     <iso3166:CountryCode>US</iso3166:CountryCode>

This has the advantage of indicating clearly, in the instance, that the 
semantics of this element come from elsewhere.  With our native element 
(see the section above for an example), there's no indication in the 
instance that we're using somebody else's stuff, unless we make a 
practice of trivially using xsi:type:

     <ISO3166CountryCode>US</ISO3166CountryCode>

     vs.

     <ISO3166CountryCode
       xsi:type="iso3166:CountryCodeType">
     US
     </ISO3166CountryCode>

*Inner vs. outer code elements

Our current design has an outer "generic" code element with a content 
model involving one or more options for specific code elements:

     <CountryCode>
       <ISO3166CountryCode>US</ISO3166CountryCode>
     </CountryCode>

The outer generic element is what gets the real dictionary entry 
explaining the code BIE, while the inner specific element(s) are mere 
mechanism.  (We haven't even figured out yet how to do this in the 
spreadsheets...)  However, I observe that XML allows you to do away with 
the outer element entirely, and embed whatever content model that 
element's type would have had into the parent object class, such as 
Address.  Is this a good idea?

	Eve

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com