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] ISSUE: Nesting and Containership within Schema

I'll start...
Excellent paper.  One additional possibility is to have a "rule" regarding the minimum number of elements that can comprise a container.  For instance, in an example from the paper we can have:
Does it make sense to have a container with only a single element?  I'm not sure, but I just wanted to bring the issue up.  I also know this may be tough to enforce, since we can have containers that contain all optional elements.

  Joseph M. Chiusano
  Logistics Management Institute
  2000 Corporate Ridge
  McLean, VA 22102
  Email: jchiusano@lmi.org
  Tel: 571.633.7722

-----Original Message-----
From: Lisa Seaburg [mailto:xmlgeek@gmi.net]
Sent: Tuesday, July 30, 2002 3:23 PM
To: Ubl-Lcsc
Subject: [ubl-lcsc] ISSUE: Nesting and Containership within Schema

Okay Library Content Group, time to get to work.  This is an invitation to discuss, keep this thread going to help us find resolution.  Thanks.
ISSUE ISThe structure of the business documents within the library seems unusually flat by XML, OO, and database standards.
NDR Comment:  While we're not against the use of sequences, we suspect that developers may find it more useful to have collections of elements that are "rolled up" into container elements at an intermediate level (for example, rows 30-31 for country sub- entities).  The classic chunking standard for human memory is 7 +/- 2, and standard operating procedure for software developers and database designers is to use this standard.
We also note that there's a lot of optionality of elements.  For example, there's nothing required in Address.  Are there interoperability consequences to this? 

If the context methodology is sufficient, is it better to allow optional elements to be made required or better to allow removal of elements? [Row 22]

Would intermediate containers help this situation at all (e.g., you can make the container optional and the contents required)? How is the "sweet spot" determined on this?  As another example, we know that there will be other kinds of things that we want to consider line items, but each kind will have a different combination/cardinality of contents.  We want to have a rule that the structures have the maximum number of required contents, and where splitting the structure into multiples will help, it should generally be done. 

Example: Line items contain at least quantity (1), part number (2), and description (3). In certain stages of the process, they also contain price information (4), tax information (5), and shipping information (6).  So you have really four kinds of line item: order, invoice, shipping, and catalog.  These should be considered different rows.
Our comment from the last face to face:   We agree.  The usage of Optional and Mandatory elements needs to be revisited on a whole.  This needs to be captured in our methodology. 
Arofan has written a containership document that has not been finished yet.  It is attached.
Tim's methodology paper addresses this also, you can also use that as reference.
Lisa Seaburg
AEON Consulting
Website: http://shell.gmi.net/~xmlgeek/
Email:  xmlgeek@gmi.net
Phone: 662-562-7676
Cellphone: 662-501-7676
"Artificial Intelligence is no match for Natural Stupidity"

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

Powered by eList eXpress LLC