[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Codelists - NIST use case - and the real requirements?
Jon, I think there are another whole hidden set of requirements here that you are not sharing with us. - solution must be W3C XSD based - no alternates acceptable - solution must allow versioning to the element and attribute level - solution must support context driven rules including o element and attribute tokenlist values o cross-field tokenlists (if A = 'value', allow B values [x,y,z] o codelist structure dependencies - (if A = 'value' element1 = required, else optional) We know the W3C schema cannot fulfil these codelist use cases - we've spent the last three weeks kicking that horse to death. Strangely enough this whole use case was part of the original ebXML work and requirements. - and therefore I am seeing that we have this solved already. Can you accept that the answer has to be non-XSD based? If not - then you have to go and get the W3C to change XSD and then wait until the parsers support whatever changes they make - and hope they understood your requirements enough that they get it right.. Otherwise I suggest we cut to the chase and recommend that people wanting extended codelist handling and validation with UBL should use OASIS CAM and the jCAM implementation to achieve that - today now - as demonstrated by the XML2004 Interoperability work - http://ebxmlbook.com/interop Can I also suggest that NIST work with that open source codebase and verify how to do UBL codelists using it. I'd be happy to work with the NIST folks on that. Thanks, DW > ================================================================== > > A Sample Extensibility Use Case > > A trading group such as an automobile manufacturer and its > suppliers want to use UBL schemas for exchange. Assume that a new > currency, FQD (Free Iraqi Dollar) comes into being and is > immediately used by trading organizations. The maintainer of the > CurrencyCode list updates the list on an annual basis, so a new > version of the standard code list is not yet available. However, > trade must go on. > > Assume that CurrencyCode "ISO 4217" is defined by UN/CEFACT and is > maintained by that organization. > > Assume that the trading partners are using the UBL-Invoice-1.0 > schema to define their order process. > > We have two XML fragments in a partner exchange: > > <cbc:LineExtensionAmount amountCurrencyID="USD" > amountCurrencyCodeListVersionID="0.3">50.00</cbc:LineExtensionAmount> > > and > > <cac:CurrencyCode>USD</cac:CurrencyCode> > > The question is, how does the trading group immediately > accommodate FQD without modifying the UBL schemas or the > CurrencyCode list schema? > >