Chiusano Joseph wrote:
><Quote2>
>Problems occur with respect to cardinality rules and context. Is
>"Address" the same within the context of a mapping source if it occurs
>within a heirarchic context of //PO/ShipperParty than when it occurs in
>//PO/BuyerParty? I think not..
></Quote2>
>
>Absolutely - this is part of our Core Components work as well. For
>example, a Basic Core Component (BCC) will have a "Cardinality"
>attribute (represented through one or more Slots) that describes whether
>the BCC is optional, mandatory, or repetitive within an Aggregate Core
>Component (ACC). We have also discussed expanding this concept to allow
>for the minimum or maximum *number* of occurrences to be specified as
>well.
>
[DN] it's a bit more complex that that. Matt Mackenzie (from Yellow
Dragon Software) and I have built some PoC stuff like this. The problem
is that the cadinality changes with the context and the order in which
contexts are applied. We have shared some of this with Arofan Gregory.
To further cite the above example, if it is a ship-to address, there may
have to be two (a postal and billing address).
>Absolutely - the Core Components RIM binding (CCRIM) that we are working
>on will be a very large benefit to our current architecture.
>
This architecture vision is written in the new UN/CEFACT eBusiness
Architecture. Core Components called it an "Assembly Doc" - sort of a
metaschema or schema for creating a schema.
It can be done today. If someone is willing to fund further
development, I am sure a publicly addressible working system can be done
within 4 months.
Duane
***************************************************
Yellow Dragon Software - http://www.yellowdragonsoft.com
Web Services & ebXML Messaging / Registry Downloads
Project Team Lead - UN/CEFACT eBusiness Architecture
Phone: +1 (604) 738-1051 - Canada: Pacific Standard Time
Direct: +1 (604) 726-3329
