Also, in the schema you can enforce that if none of the elements
within a container appear (if they are all optional), then the container
(wrapper) element will not appear. This would prevent empty container
elements if we didn't want to have them.
**************************************************************************
Joseph M. Chiusano
Logistics Management
Institute
2000
Corporate Ridge
McLean, VA 22102
Email:
Tel: 571.633.7722
**************************************************************************
-----Original Message-----
From: Lisa Seaburg
[mailto:]
Sent: Tuesday, July 30, 2002 4:17
PM
To: Ubl-Lcsc
Subject: Re: [ubl-lcsc] ISSUE: Nesting and
Containership within Schema
Good points, especially the last. Should we
have containers that contain elements that are all optional, so that you could
have an empty container element?
----- Original Message -----
From:
CHIUSANO,
Joseph
To: Ubl-Lcsc
Sent: Tuesday, July 30, 2002 2:47
PM
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:
<tax.identifier>
<tax.identifier.code>
</tax.identifier>
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.
Regards,
Joe
**************************************************************************
Joseph M. Chiusano
Logistics Management Institute
2000 Corporate Ridge
McLean, VA 22102
Email:
Tel:
571.633.7722
**************************************************************************
-----Original Message-----
From: Lisa Seaburg
[mailto:]
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 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:
Phone:
662-562-7676
Cellphone: 662-501-7676
"Artificial Intelligence is no match for
Natural
Stupidity"
++++++++++++++++++++++++++++++++++++++++++++++++++++
