OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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?)

> 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.

> 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.

 > 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.

	Eve

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC