Cart
[Home] [By Thread] [By Date] [Recent Entries]
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... fn:Patrick Ohl end:vcard
|
