[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
Powered by eList eXpress LLC