In a previous entry, I argued on the need for native XML support in the Java programming language. During the last couple of days, there have been some interesting reactions which I would like comment on.

XML Schema issues
Fred is worried about how we would go about validating an XML instance document against its corresponding schema. As I said in my answer to him, it should be possible to provide the schema and an optional error handler as further arguments to the Document constructor. Another solution to this would be the one proposed by IBM's XJ project as pointed out by Steve in his blog.

Ignoring annotations for now, the most interesting tangible stuff on adding XML to Java is IBM research's XJ, which looks very cool indeed. Automatic import of XSD files, inline xpath operation. The latter is what is nice. I bet you could implement a SOAP stack there nice and quickly. Mukund Raghavachari, the project lead, contacted Ed and I to say that a new release is coming soon. But will XJ become Java7? Oh, there are some interesting politics there. Let's see, "will sun hand over innovation of the Java language to its main competitor?". Probably not, no. Maybe it's time to fork the language.

XJ features are quite impressive and the project is a first step into the direction I expressed. The good thing is that since all the binding work is done a compile-time there is no need for runtime error handlers. Letting politics aside, I think that with some polishing, it could even make it into Mustang, disregarding the advertised limitations, of course ;)

Jokes aside, let's rewrite the purchase order example using XJ. Furthermore, let's say that the related purchase order schema called po.xsd is stored in the com.mycompany.myproject package. The code would now look like this:

//Tell the XJ compiler to use the po.xsd schema.
import com.mycompany.myproject.po;
...
//Retrieve the purchaseOrder object from the XML instance document
purchaseOrder po = new purchaseOrder("po.xml");

//Retrieve all partNums and compute the grand total for the purchase order
double total = 0;
Sequence<item> items = po[|//item|];
XMLCursor<item> itemCur = items.iterator();    
while (itemCur.hasNext()) { 
   item it = itemCur.next();
   System.out.println("partNum:" + it[|@partNum|]);
   total += new Double(it[|./USPrice/text()|]);
}
System.out.println("Grand total = " + total);

We still have some metalevel clutter with the Sequence and XMLCursor stuff. Furthermore, XPath has to be supported natively by the compiler as well, which is not necessarly a good idea in my opinion. I would prefer to use a dotted notation for navigating through the XML element hierarchy. Aside from those details, the code looks waaaaay nicer and is much more concise than the other two DOM alternatives. I'm eager to see how the new release of XJ will look like.

IDE Code Completion issues
Someone raised the interesting issue of how IDEs may continue to provide code completion features if native XML support was to be included in the Java language. As seen above, the xjc compiler not only compiles conventional Java code as do all other Java compilers, but it is also able to process XML schema and dynamically build the corresponding Java classes. The XJ compiler seems to provide some sort of implicit O/X mapping at the compiler level. So, as soon as an XJ file is compiled, all the typing information contained in the XML schema is available for use. The only thing is that with XJ you cannot invoke methods on the reified XML elements. The only way to access their children or attribute values is by using XPath expressions. As I see it, this is a big limitation of the current XJ release.

XML as a programming language
To me, providing native support for XML in the Java programming language and considering XML as a programming language per se, are two different things which we must be very careful not to mix. In a recent blog entry, Steve argues that there is a natural syntactical bridge between XML as a data format and XML as conventional code by using a Scheme clause analogy. He says:

So you cannot say that code-in-XML is inherently wrong, as there is clearly a two-way transform at the syntactic level from an XML document into a scheme clause, and since scheme is an elegant and powerful language, so there is an elegant and powerful way to work with XML, within a representation of the document itself.
All you need therefore, is (1) an appropriate expression evaluation engine and (2) a representation for XML that you are prepared to work with. It is unfortunate that classic-XML is not the best structure for humans, S-expressions are neater once you get used to them -but spend enough time and XML becomes readable too. All that leaves is the appropriate expression evaluation language. No, I dont think water is it either. It looks a bit LISPy, but seems to be trying to do that inside content markup.

OK, now I'm worried. I didn't say that code-in-xml is wrong, just that in my opinion XML is neither suitable nor intuitive for this kind of usage and that it has not been invented for that purpose. Scheme is an old horse, on which I haven't been riding much over the last couple of years, so I'm a bit rusty. If memory serves me right, fully nested notation might well remove tricky ambiguities and is well suited for a computer to process but it is definitely not intuitive at all to us human beings because this is not the way we are used to process information. I don't question the expressive power of Scheme or any other similar functional languages for that matter, but please tell me whether it is easier for a human being to understand "the cat drinks milk and the dog eats meat" or "and drinks the cat milk eats the dog meat". Sorry, it wasn't fair, I forgot to include the necessary parenthesis without which all these words don't make any sense at all since all the contextual information is lost. The correct sentence would look like this: "(and (drinks (the cat, milk)) (eats (the dog, meat)))".

To me, what really counts is that we can write programs in languages that most closely ressemble our because WE are programming those machines and not the other way around (letting the Matrix philosophy aside, of course). Since the dawn of computer sciences, people seem to recurringly come up with new ways of making it easier for the compiler to process software code instead of making it easier for humans to create software. I don't care whether the compiler will have a hard time compiling my stuff, what I do care about is that I can write software for my customers in a language that is most closely related to mine and not to the computer's. I don't see why we should always have to lower ourselves down to the computer level instead of bringing the computer up at our level. At the end of the day, what I really want is to create solutions (i.e., software) for solving problems (i.e., customer needs) and this can only be done efficiently if all people who take part in the creation of these solutions have the right tools and languages that are best suited to their needs and that very closely mimic the way they communicate together. In my opinion, 4GL and 5GL languages are part of the key to efficient, productive and focused information system development.