[ubl-lcsc] 9/16/2002: Capturing the position reached re: ListContainer Types

[Monica Martin <mmartin@certivo.net>]

Comments to your comments, Eve.  See inline with mm1:.

-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Wednesday, September 11, 2002 8:45 AM
To: 'ubl-ndrsc@lists.oasis-open.org'; 'ubl-lcsc@lists.oasis-open.org'
Subject: Re: [ubl-lcsc] Capturing the position reached re: list
container types.


Great (and accurate) summary.  I'd like to add just a tiny bit more 
context around the edges...

Tim McGrath wrote:
> My apologies if my notes here do not reflect other's opinion on where
we 
> got to with this discussion.  This is not intended to be a complete 
> record merely a point from which we can continue on the wednesday
call.
> 
> We started from a point where we suggested the possibility of 'basic' 
> list containers and 'semantic' list containers. 
> The basic list were containers that wrapped a set of elements or a 
> container of elements. The example we used was orderline being wrapped

> by a list of orderlines.  This would enable processes to handle the
set 
> of orderlines as one object.  We discussed the fact that these could
be 
> assumed as part of the cardinailty of an ABIE's occurrence in our 
> logical model.  Wherever we had the possibility of multiple
occurrences, 
> we could implement a 'basic' list container.  This suggested that
these 
> need not be part of the logical model or if they were it would be as 
> metadata in the model stating if a list container was deemed
appropriate 
> in the schema.
> We then considered a point raised by Bill Burcham that XML processes, 
> such as XSLT, could deal with XSD definitions in these sets without
the 
> need for additional wrappers.  The addition of another layer of 
> container/wrapper to cover 'list of's brought some overheads and may
not 
> be as beneficial as first thought.  This thread wasn't concldued but
we 
> started to feel that we could adopt an 80/20 rule and avoid this type
of 
> container in our schemas.
> 
> The second type of list container were those that added additional 
> information to the set of ABIEs they covered.  The example we
considered 
> was...
> "an order was for ten shirts and each shirt had a common set of 
> features, for example they were ordered in the same set of six
different 
> colours."

In particular, we were imagining that this would be a customization, 
since it doesn't seem to have arisen in the "vanilla" ABIEs we've got so

far.  In order to add the "common" information to a set of line items 
using XSD derivation, you would (in practical terms) need an element to 
hang them off of.  A list container would be the likely candidate; you 
could add them to the order as a whole, but if you do the functional 
dependency analysis, the set-of-colors information logically varies per 
group of line items, not per order.  (Then again, this may be sort of 
moot if there's only ever *one* group of line items in the order...is 
that right?)

[mm1: There may be more than one group of line items and subline items
within a line item
is very possible (to different shipping locations, for example).

> The question then posed was, is it reasonable to add the BIEs/elements

> that describe these colours to the  List of Orderitems container
rather 
> than repeat them for each Orderitem?  This means the list container
now 
> has semantic value (it has information we cannot find elsewhere).
> It was suggested that this scenario arises because we want to have the

> non-redundancy of relational structures in hierarchical XML documents.

> In fact, this was one of the motivations to move from hierarchical 
> database systems to relational ones.

A little more detail here.  We discussed the technique of factoring out 
some information and having it apply to a group of line items.  There 
are various ways to do this with XML containment, but each would feel 
more like a view of an RDB than a true reflection of the relationships. 
  (E.g., if three line items had one shipping address, and another four 
line items had a different shipping address, you could have a 
shipping-address-primary container for each of the groups of line 
items.)  But if you're looking for economy of expression *and* (at least

some) neutrality as to what's "primary" in the association, you'd 
probably want to supply various shipping addresses with symbolic 
identifiers on them, and then have each line item reference the desired 
address.  To customize UBL to do this wouldn't, in fact, require any 
list containers to have been present in the original.

[mm1: See previous comment, you could have multiple line item
'containers' and multiple ship to locations per line
item. For example, you have (5) boxes of shirts ordered - (3) to
Location A, (1) to Location B and (1) to Location C - total
of 5 boxes.]

> On further debate, it was suggested that many of these situations were

> examples of new ABIEs rather than lists of  existing ABIEs.  This was 
> one of the points Bill Burcham made in his comments.  

In other words, "semantic" rather than "basic" lists using the 
terminology introduced at the top.

[mm1: The semantic meaning is introduced at several levels, most
importantly in business context.  If you artifically
provide that 'container,' are you changing the business context of which
it was defined?

 > It may be that
> what we are discussing is exmaples of normalization (certainly the 
> orderitem/colour example appears to be that). Furthermore, if we were 
> finding it difficult to find cases that required this type of list 
> container (and weren't new ABIEs) then maybe our 80/20 rule again
comes 
> it to say they are not significant.
> 
> In summary,  we saw a shift in the original suggestion and may now be 
> suggesting that 'list of'-type containers are not as significant as we

> originally believed.
> 
> Now, on with the 
> show.........................................................

For the record, here's where I came out at the end of yesterday's 
discussion -- opposite from how I started:

- The overhead of basic (syntactic) list containers seems not to be
   worth the extra power you get in customization.

- We might find an occasional semantic ABIE that contains series of like
   elements (plus possibly an unlike thing or two), but it should rely
   on a regular analysis of functional dependencies.  This discussion
   has opened our eyes to this possibility, and suggests the various
   0..n and 1..n properties should be briefly re-examined for missing
   opportunities, but there's no need for wholesale changes.

[mm1: I still see that this structure could be 'created' when specific
context is applied by the ultimate user in creating the business
document instance.  They alone would understand where things fit.]

	Eve

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>