I've summarized Eve's argument in outline form below to highlight which parts I agree with and which parts I dispute. My arguments are mixed into the outline... 1. list containers are necessary in the physical model (*DISPUTED*) 1.a. containers (general) are useful (*AGREED*) 1.b. list containers (particular) have great value (*DISPUTED*) 1.b.1. (this point works against the thesis): the equivalent of DTD nested parenthesized groups can be adequately modeled by introducing a complex type for the nested group. I'd say further that any argument that starts from a DTD construct with no analogue in XSD is a non-starter since UBL has standardized on XSD. 1.b.2. (this point works against the thesis): multiple (neighboring) series of like items are unambiguous. There is no need to introduce extra intermediate "container" elements. Demonstrated by the discussion and the XSLT example. 1.b.3. (*DISPUTED*): reference to (earlier) argument about easier customization afforded by "general container" elements. Here's the crux of that point verbatim: "If a trading community ever wanted to add some *un*like elements to a collection of like elements (such as metadata that applies across a whole line item list), the only honest way to do this in XSD is to hang the additions off a LineItemList structure. (It would be extremely difficult and ugly to add a list container in the customization that wasn't present in the original.)" It seems to me though, that once one adds *un*like elements to a collection of like elements, that collection ceases to be a collection of like elements and becomes *indistinguishable* from what we would all agree is just a "plain old" ABIE. In that case, would we propose that the new ABIE follow the same rules? Take for example, this instance document: <!-- *original instance document HYPOTHETICAL* --> <!-- content conforming to ABIE1 --> ... <BuyerAddress>...</BuyerAddress> <LineItemList> <!-- content conforming to first-class CONTAINER1 --> <LineItem>...</LineItem> <LineItem>...</LineItem> <!-- end content conforming to first-class CONTAINER1 --> </LineItemList> ... <!-- end content conforming to ABIE1 --> Now let's specialize the first-class container "LineItemList" to add "Height", "Weight" and "ShoeSize"... <!-- *specialized instance document HYPOTHETICAL* --> <!-- content conforming to ABIE1 --> ... <BuyerAddress>...</BuyerAddress> <LineItemList> <!-- content conforming to first-class CONTAINER1-PRIME --> <LineItem>...</LineItem> <LineItem>...</LineItem> <Height>...</Height> <Weight>...</Weight> <ShoeSize>...</ShoeSize> <!-- end content conforming to first-class CONTAINER1-PRIME --> </LineItemList> ... <!-- end content conforming to ABIE1 --> But what ho! Look at those nasty (repeated) "LineItem" elements -- boldly mixing with their (different) neighbors (Height, Weight...) -- unsegregated by a sheltering container element. We've violated the proposed rule that all containers of like items be explicitly represented by a (container) element in the instance document. To resolve this, we have to modify the specialization like this: <!-- *specialized-2 instance document HYPOTHETICAL* --> <!-- content conforming to ABIE1 --> ... <BuyerAddress>...</BuyerAddress> <LineItemList> <!-- content conforming to first-class CONTAINER1-PRIME-2 --> <LineItemList> <LineItem>...</LineItem> <LineItem>...</LineItem> </LineItemList> <Height>...</Height> <Weight>...</Weight> <ShoeSize>...</ShoeSize> <!-- end content conforming to first-class CONTAINER1-PRIME-2 --> </LineItemList> ... <!-- end content conforming to ABIE1 --> But wasn't the whole point of the proposal that it be "easy" to extend containers of like items to contain unlike ones? I guess it was easy -- the first time, but the resultant specialization (CONTAINER1-PRIME) broke the proposed rule. It suffered the supposed ills we were trying to eliminate. The proposed rule pushed the problem down from the ABIE1 type to the CONTAINER1 type. In order to apply the proposed rule consistently, the CONTAINER1 type was forced to undergo wholesale restructuring (CONTAINER1-PRIME-2). Did the proposed rule achieve anything new and positive with respect to XSD derivation? For instance, it would be good if CONTAINER1-PRIME-2 were a subtype of CONTAINER1. Unfortunately that's not possible since CONTAINER1 specified zero or more LineItem and CONTAINER1-PRIME-2 specifies essentially "zero or zero" LineItem (LineItem is "pushed down" under LineItemList). Also, I see no qualitative difference between CONTAINER1-PRIME or CONTAINER1-PRIME2 and any other ABIE. CONTAINER1-PRIME is no longer a container of like elements -- it's now a generalized object=relation=entity with attributes and associations. It just so happens to have, among other attributes, an association to one or more LineItem. Since Eve introduced this whole "intellectual honesty" idea ;-) I guess I should allow that there is precedent in OO, ER and other data modeling methods for the idea of "first class association" and "first class container". Container is the retrograde case of the more general association. A container of like items can be modeled as a 2-way association (i.e. an association between two classes/entities) with navigability in one direction only. An association may in general be N-way and have navigability in many directions. The analogue between "first class container" and the proposal at hand would be to explicitly model each container type, and to allow subclassing of those to add attributes. For instance List of LineItem or List<LineItem> would appear in the logical model and it would not be unusual to see a subclass of List of LineItem that adds attributes (and semantics) to the base class (in our example CONTAINER1-PRIME-2). My experience is that this this is almost never the approach taken by experienced designers in environments where containers are the lingua franca (languages like SmallTalk, Java, C++). In those environments, container semantics are used "as is". ** Composition with, and not specialization of, containers is the preferred form of reuse. ** There is support in the literature and practice of ER and relational modeling for first class associations. Neither the Core Components Technical Specification, nor XML Schema have a way to represent general (2-way or N-way) associations. Since XML Schema can't represent them, their only possible use by UBL is in the logical model. That being said, it has been my experience with enterprise data models (granted, not Universal ones like UBL) that the number of associations modeled in this first-class way is small relative to the total number of associations in a model. I daresay that the UBL 80/20 rule would dictate here that such first-class associations be construed as comprising the "20" case and therefore relegated to "exception" status rather than "rule" status. One last issue occurs to me. If it's so important to have "container" elements for sequences of like items, then why isn't it equally important to have container elements for associations to (single) items. What's so special about "1..n" and "0..n"? Is it not true that a "1..n" or a "0..n" can become a "1..1" via contextual specialization? If one thinks about this from an XML instance document perspective one arrives at structures reminiscent of the "old days" of global element declarations in which "types" were validated based solely on tag names so any situation where the global tag name didn't make sense necessitated an intervening tag. But XSD solves that problem for us by introducing the notion of a type, the name of which need never appear in the instance document. This frees our tag names to be descriptive of the _role_ of each element relative to its (I'm going to say it) CONTEXT! Thus what would in general have been a 2*N deep structure (in the old days) becomes an N level deep structure. Now for those of you who will poo-poo this a mere optimization-ism -- remember, that ain't no constant factor there -- the factor of 2 goes in the _exponent_ since an XML document instance is a tree. 2. list containers are necessary in the logical model (*DISPUTED*) 2.1 because list containers are necessary in the physical model they are necessary in the logical model (*DISPUTED*) The foregoing discussion was meant to take the legs out from under point 2.1. I believe that Eve and I have shown that list containers don't really solve any problems in the physical model, and that therefore any arguments built on that premise must be supported by other means. Bill Burcham Sr. Software Architect, Standards and Applied Technology Sterling Commerce, Inc. 469.524.2164
bill_burcham@stercomm.com < mailto:
bill_burcham@stercomm.com >