RE: [xml-dev] XML should NOT be a new programming language

["Dare Obasanjo" <dareo@microsoft.com>]

It looks like I overlooked your post before sending out my last email.
Most of the things you mention in your post are already a reality to
thousands of developers using C# and .NET today. I'd be interested in
some of your thoughts on whether the XML serialization technologies in
.NET meet some of your needs. 

For more details on how XML serialization works in .NET try 

	
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconserialization.
asp	

PS: If you are interested in figuring out C# so as to better understand
the code samples you can try reading this article which is aimed at
giving Java developers a birds eye view of the similarities and
differences between C# and Java. 

	http://www.prism.gatech.edu/~gte855q/CsharpVsJava.html  

-- 
THINGS TO DO IF I BECOME AN EVIL OVERLORD #51
If one of my dungeon guards begins expressing concern over the
conditions 
in the beautiful princess' cell, I will immediately transfer him to a
less 
people-oriented position.


> -----Original Message-----
> From: Patrick Ohl [mailto:Patrick.Ohl@o-h-l.de] 
> Sent: Sunday, March 03, 2002 3:55 AM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] XML should NOT be a new programming language
> 
> 
> 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)