[ubl-lcsc] 8/1/2002: ISSUE Nesting and Containership within Schema

[Monica Martin <mmartin@certivo.net>]

A couple of comments....Optionality has created challenges with
RosettaNet - so that is a lessons learned.  It also creates some
challenges in implementation and particularly conformance when you don't
have required or mandatory elements (at some level).  If you defer to a
required container, can that container be empty (as you can't determine
if the elements within the container will be used - benefit, but
challenge of extensibility).
 
The more you decouple, the more the complexity (and flexibility) for
implementation and testing. Wouldn't you be concentrating on the
elements and the fact they can be constructed, and leave to how they are
constructed, present and used to implementation?
 
More later.
Thank you.
Monica J. Martin
Program Manager
Drake Certivo, Inc.
208.585.5946
 
 

	-----Original Message----- 
	From: Lisa Seaburg 
	Sent: Tue 7/30/2002 1:22 PM 
	To: Ubl-Lcsc 
	Cc: 
	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 IS:  The structure of the business documents within the
library seems unusually flat by XML, OO, and database standards. 
	 
	**********Comments**********************
	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 <mailto:xmlgeek@gmi.net> 
	Phone: 662-562-7676
	Cellphone: 662-501-7676
	 
	"Artificial Intelligence is no match for Natural Stupidity"
	++++++++++++++++++++++++++++++++++++++++++++++++++++