[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] New code list issues
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC