[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]