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: [ubl-lcsc] Capturing the position reached re: list container types.


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


-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 





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


Powered by eList eXpress LLC