The many to many problem in XML,was the BSR - the Basic Semantic Register

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Philip Goatly shares with us two scenarios which he would like to
contemplate involving the standard carton (the same SKUs packed within a
shipping container) and pick-pack (different SKUs packed within the
shipping container) packing configurations.  See
http://lists.ebxml.org/archives/ebxml-core/200101/msg00149.html.

Bob Miller "would [accommodate] that by designing hierarchical message
constructs to the extent that they model real world hierarchical
relationships."  Presumably, Bob would favor mapping Goatly's examples
just as shown, without any attempt to "flatten" the structure for
benefit of relational databases.  Then Bob "would augment that design
with relational message constructs to handle the relationships (key/key
relations) that are not directly addressed by the hierarchical model."

I would add to Bob's comments that there's probably never any need to
come up with artificial keys, as in the real world each of Phil's
<Product> items can be identified with the SKU or a UPC/EAN number, and
the <Container> objects almost always likewise have a standard marking,
whether a bar-coded UCC/EAN-128 Serial Shipping Container Code or a
shipping label number or suchlike.

I'm having a hard time discerning the problem Phil is alerting us to:
if you wanted to flatten out the structure, you could simply take each
level's key from the hierarchy and add it to the relational DB record.
In any case, I'd rather have the real world hierarchical relationship
shown in the XML data, taking advantage of what comes natural to XML
(i.e., Element Content and nesting), rather than some artificial flat
structure mimicking DBase comma-separated files.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"