No Subject

(3) Encapsulation and Java Binding:

Many tools for working with XML use a Java binding that equates elements
with java classes, which are then provided with "get" and "set" calls for
things like child elements or attribute values. This is true of such tools
as JAXB from Sun, and many other, similar technologies. (If you think about
it, this is very much the way we have done our data modelling, but in
reverse! Each class in the data model becomes an element/type in the XML
structures.)

In object-oriented programming languages, encapsulation works to simplify
and make more readable the code that is created. In our case, if I want all
the "header" information in a business document, and I am using a Java
binding as characterized above, I will need to deal with a set of a
half-dozen or more objects in order to construct or read from the document
object, as opposed to having a single object that encapsulates these. When I
want to get all of the body-type elements - items - from my order, I would
like to have a single object (a "body" object) that represented an array of
like objects (items), as this simplifies the code that reads or creates
these items in the document. In processing terms, the header and body
information is quite different - often, the "header" information provides
the context in which the items in the "body" are processed, so a division at
this level makes a great deal of sense from the point of view of object
encapsulation.

(4) Extension Methodology:

The current Op70 release is fairly adequate from this perspective, with the
exception of the lack of division of the document into "header" and body"
elements. (This argument does not apply to "lists" elsewhere in the document
structure.) Because XSD extension only allows us to add elements at the
*end* of existing structures, any additions of header-type information I
make at the document level will have to appear after all of the items in the
document. This exacerbates all of the problems stated above: because I can't
add an element to the header information (there not being a containing
element for header information), I have some header information before the
items, and some afterwards. This is extremely confusing to users, and
suffers from all of the processing inefficiencies stated before. It is also
suceptible to the same solution - the addition of a containing element
around the header information, so that header extensions could be added
there.

Note that this effect also complicates SAX-type processing. Often,
header-type information sets the stage for item processing, by establishing
who is placing an order, for example. When processing without benefit of a
DOM, added header information that appears _after_ the items of the document
would require a second pass through the XML instance, to determine what to
do with the items in the instance, assuming this header information is
needed to understand how to process the items. This negates much of the
efficiency advantages of SAX processing over DOM processing - the use of
memory to record the contents of the document while processing.


Recommendations:

The recommendations here are simple, and easily expressed as rules that
could be automatically enforced with the scripts that generate the XML
structures:

(1) All documents are divided into a "header" section and a "body" section
(which division is already implicit in the contents of the messages in Op70,
a suspicious fact when you consider the usability arguments above...), using
some simple naming rules based on the name of the document-level element.
These constructs, if deemed to have semantic content, could appear in the
business models; alternately, they could only appear in the XML and the
implementation models. (On this point, I am agnostic, but I would like to
point out that there is no requirement here to impact the work of LCSC at
all!)

(2) All elements that have a cardinality of 1..n or 0..n should have a "list
container", the name of which is created by adding an "s" to the end of the
child element contained (or otherwise pluralizing it). Again, this need not
be a semantic construct appearing in the business model, but could simply be
a construct in the implementation model. There is no need for the work of
LCSC to be altered.



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>