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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[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?
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]