[
Lists Home |
Date Index |
Thread Index
]
Hi,
First of all I have to admit, that I fully understand the concerns of
Niels Peter.
Me, too, I don't think we should specify to much behavioural things in
XML. XML is a document structure and with this an annotated data
language. You can see this in the JSP/ Java Servlet twist. Java Servlets
are good to define funktion but become a pain if we put too much HTML
fragments in it. So we have JSP, good for dynamic HTML scribbling, but
unhandy if the functionality is too complex... (-> Model 2 architecture)
I always wanted to modify my data, to be precise my xml documents, in
Java as well. Java or any other mature programming language with its
languae constructs and supporting API will be mightier than any xml
script language, which is still readable.
"Thomas B. Passin" wrote:
>
> [Mike Champion]
>
> > There are parsers that take non-angle-bracket syntax and generate SAX
> events
> > (I can't point to any offhand)
>
> I'm sure many people on this list have done this. I've got a little system
> that uses an indented format inspired by Python formatting - something like
> YAML, it turns out, but a bit different. I wrote a Python parser that
> throws SAX events and have a writer that can output xml. It's a great way
> to whip up a modest amount of xml by hand, and it's very readable, you can
> see the structure more easily (it can't capture all xml constructions, but I
> don't care).
>
> It would be interesting to learn what other kinds of non-xml SAX generators
> people have written. Anyone care to say?
In my diploma thesis I analysed the current concepts to integrate XML
documents in Java applications. To integrate as to read, modify and
write. There are more concepts than SAX and DOM. And there are better
concepts as well. Never the less, they are still all 'beta' or let's say
not that rock solid stable than good old SAX (which will have it's forth
birthday soon!).
You can put them into three categories:
1. Eventdriven Interfaces:
SAX is the big standard here. It is reliable and basis for most other
APIs. Altough (nearly) everything can be done using a SAX API, the
development effort is huge. Developers have to be both be aware of XML
and of the SAX API, which is - especially for an object-oriented
thinking person - not always intuitiv.
2. Generic, tree-based interfaces:
Such as DOM (and JDOM, dom4J and so on). These are quite intuitive to
understand. Still in object-oriented context they are a good example of
the 'functional decomposition' anti-pattern [1]. As generic tree-based
interfaces are solely a data structure, which cannot be extended by the
user, you have to split te data from the functionality that work on the
data. This is not what is meant by object-orientation. (People halp
themselfs by building Wrapper classes or traversing the tree structure
to extract the data into a new object model.)
So this is where the third generation tools and APIs come in. How can we
transform object containing data and functionality to xml documents or
create these structure from an xml document?
3. XML data binding
These are a couple of new conecpts to integrate xml documents in (java)
applications. There were already some threads on this list discussing it
( http://lists.xml.org/archives/xml-dev/200105/msg00972.html ). For a
very good list of resources see [2]. Sadly most of these tools and APIs
are still in development. Data binding can as well be catagorised into
three different concepts:
3.1 XML serialisation
An analog approach as javas binary serialisation. The difference is
that the output/input format is a (wellformed) xml document. The big
disadvantage is that we cannot specify the xml documents grammar, which
is given with the XML serialisation implementation. Very easy to use,
but not practical in most cases, where we have to process/generate a
document following a specific grammar/DTD. (Well, we could transfor the
input/output with XSLT. But that is just the problem we come from...)
Examples are:
J.A.D.E.: http://jade.dautelle.com
JSX: http://www.csse.monash.edu.au/~bren/JSX/
JOX: http://www.wutka.com/jox.html
3.2 Mapping libraries
If we want to specify the xml document's grammar, we have to specify
mapping information. This is the concept of maping libraries. They
transform the arbitrary object to xml according to specified mapping
scripts. Quite cool. That's just what we wanted. The disadvantage: we
have to define te mapping information. In most cases this is a XML
syntax as well, so Niels Peter won't like it. If you have a look at the
examples of JATO http://www.krumel.com/jato/ you can imagine, that for
more complex documents or object structures the mapping information
definition gets unreadable as well.
3.3 source code generators
So what to do? The next concept should suite Niels Peter. If we can
restrict the (java) application to use one single grammar and we have a
relatively stable version of the grammar at development time we can use
source code generators. These generators parse a specified grammar and
construct a set of classes (or constructs of a programming language).
Instances of these classes are then a representation of a (valid) xml
document following the specified grammar. With the help of certain
utility classes we can serialize a object structure to or deserialize
from a xml document. We have nearly no contact with xml and can work on
and modify the generated classes.
The big difference between this concept and generic tree-based API is,
that different element declared in the specified grammar result in
different programming language construct. Wth the generated source code
available we can include the behavioural aspects directly into the
generated classes. This can happen in superclasses and subclasses as
well. So we have a object model which is analog to the ml documents
structure including all functionality we need to work with it.
Sounds like a comercial, doesn't it? Well, okay - I did build a source
code generator. It is freely available at
http://www.jNerd.de/xml2java.html . There are other implementations as
well. The most widely know should be the Java architecture for xml
binding (JAXB) from Sun microsystems. (
http://java.sun.com/xml/jaxb/index.html ) It still has - in my opinion -
some defects (e.g. you cannot specify superclasses, no javadoc, no
access to the serialisation/deserialisation logic, IDREFs are strings
not associations...), but it will probably be the future tool to
integrate xml document in java. (Who wants to rely on a tool by some
unknown student from third world germany??)
Other source code generators are:
Castor: http://castor.exolab.org
XDK: http://otn.oracle.com/software/tech/xml/xdk%5fjava/content.html
Zeus: http://zeus.enhydra.org
Breeze XML Studio:
http://www.breezefactor.com
For a complete or let's say bigger list see [2]. Ronald Bourret
categorizes the concepts into run-time tools/APIs which include 3.1 and
3.2 concepts and development tools which include 3.3.
Hmmm, long mail. I hope I could help someone or spead some new thoughts.
Greetings,
Patrick
[1] William J. Brown, Raphael C. MAlveau, Hays W. McCormick III, Thomas
J Mowbray,
"Anti Patterns", John Wiley & Sons, New York, 1998,
ISBN:0-471-19713-0
[2] Ronald Bourret, "XML data binding resources",
http://www.rpbourret.com/xml/XMLDataBinding.htm
[3] Patrick Ohl, "Von XML nach Java - Spezifikation und Entwicklung
eines DTD-getriebenen Generators fuer ein XML-Dokumentenmodell in Java",
Diplomarbeit, Technische Universitaet Muenchen, November 2001,
http://www.jNerd.de/DA.pdf (in German)
begin:vcard
n:Ohl;Patrick
tel;cell:+49-1708607430
tel;home:+49-89-38859084
tel;work:+49-89-358680-45
x-mozilla-html:FALSE
url:http://www.jNerd.de
adr:;;Ainmillerstr. 6;Munich;;80801;Germany
version:2.1
email;internet:Patrick.Ohl@o-h-l.de
fn:Patrick Ohl
end:vcard
|
