Farrukh,

Added to this - we definately need to gather together the business use cases. Obviously simple codelists are a no-brainer:

<codelist name="Currency codes" type="currency" UID="XXX123456"> <member value="USD" description="US dollar"/> </codelist>

type of thing etc - but in the realworld we have extended needs to be able to cleanly interoperate between partners and manage the changes and deltas - your example of Argentinian currency codes and exchange rates is a good one.

Not to mention business context.

In the CAM system we've engineered a lookup() function that is extremely flexible - and obviously we want that to optionally be able to use codelist values retrieved from registry - so having a common format is a major plus.

Like you I sense this can potentially all come together nicely, and for each of the common business use cases of codelists (there's about five or six of these) we can show how to engineer and configure the codelist mechanism to give the desired behaviours.

I'd re-draw your diagram with a bit more fine detail, something like:

|--------------------------------------------------------------| | UBL Business Document instances | |--------------------------------------------------------------| | CAM template | UBL Business Document Layout choices | | | Business rules and content references | |--------------------------------------------------------------| | Business Context | Core Component BIE | |--------------------------------------------------------------| | Core Component nouns and codelists | |--------------------------------------------------------------| | ebXML Registry Information Model (ebRIM) | |--------------------------------------------------------------|

And of course the UMM model sits above this providing the business picture, with the BPSS controlling the processing and determining the context and the transaction instance requirements.

All good customers for registry services of course.

Thanks, DW. ===================================================== Message text written by Farrukh Najmi

-It is extensible and can handle current and future requirements for mapping UBL code lists

-It Enables hierarchical code lists (as in UN/eDocs LoCode, Argentinian currency use cases)

-It provides one common XML schema may be used to represent any code lists

-It makes it easier to manage UBL code lists in an ebXML Registry enabling automatic content specific cataloging and content specific semantic validation.

While it will take some time for the dust to settle, a desirable outcome could well be that CCTS uses ebRIM to define its serialization format, UBL uses Core Components BIEs and therefor indirectly uses ebRIM format as the picture below shows:

|--------------------------------------------------------------| | UBL Business Documents | |--------------------------------------------------------------| | Core Component BIE | |--------------------------------------------------------------| | ebXML Registry Information Model (ebRIM) | |--------------------------------------------------------------|