What's So Great About XML?

November 8, 2000

Didier Martin

A web developer recently asked me this question. He had created several applications producing HTML or WML documents, to be rendered on ordinary browsers or mobile phones. From there the conversation moved on to discussing XML-based content delivery architectures.

John: "What's so great about XML? We have more than enough tools today to do the job. For instance, I can use JSP to create WML or HTML applications. Even better, I can connect to legacy applications or data sources. I cannot do that with XML tools"

Didier: "You are not considering XML database tools like Oracle or Microsoft's SQL server. These two tools can produce and transform XML documents from relational databases."

John: "Right, these tools can do that. But what about a CORBA object that is accessible only through IIOP? You know, in the telecommunication field there are a lot of these objects. How can XML tools help there?"

Didier: "So your point is that XML technologies do not take into account that we need to connect to all kinds of data sources and not only to connect to relational databases?"

John: "Exactly."

Didier: "OK, good point. so how do you deal with device independence?"

John: "Easy, in the Java world you create Java beans to encapsulate the legacy data and you create a JSP for each device. The JSP scripts uses the Java beans your created."

Didier: "But what if you modify one of the object's methods? You modify all your scripts then? If you have several devices to support, and if these devices are all different, don't you think it could be a maintenance nightmare?"

John: "But I have only two devices to support."

Didier: "For the moment yes, you support WML and HTML. But let's say that you have to support WML, VoiceXML, HTML for big PC screens, and HTML for small screens PDAs. You have now to modify four scripts, don't you increase the risk of dropping one of your balls by juggling with too many scripts?"

John: "No problem, we have good tools to manage this. So let me ask you a question now. How would you resolve this?"

Didier: "Since we are talking about using Java to connect to legacy data source or objects, then let's use Java. First, I would create a Java servlet or JSP document that connects to data sources and objects, and this servlet or JSP document produces an XML document. So the first difference is that I'm using JSP to produce an XML document -- not a rendering document, a modeling document"

John: "Yes, but today no browsers are able to render XML documents. So your solution is too far away..."

Didier: "John, you're jumping to conclusions. Yes, you are right in saying there are no browsers on the market that can use XSLT, if this is what you meant."

John: "Exactly."

Didier: "It's OK, we can still resolve the problem even if the client's devices cannot transform the XML document into a rendering format. The whole trick is

• to produce an XML document using a piece of code. It could be Java, C++, Python, or any other language. The important point to notice here is that we have a single copy of procedural code to maintain. So, a single script containing procedural code produces an XML document for all the devices.
• Then, the server has to detect the capabilities of the client device. If the device understands WML, then the server has to transform the document from its actual structure into a new structure conforming to the WML schema. Same thing for the other schemas or document types."

John: "Would you use XSLT to transform the document?"

Didier: "Yes or another transformation language like DSSSL. It's a matter of taste, skills, and knowledge. I would use a language able to transform one XML document type into an other."

John: "Why not create the rendering format directly? Why use a complicated sequence?"

Didier: "Not too complex John, you have only two main processes: create an XML document and then transform it into a rendering format. In other words, create a model then transform it into a view. John, you've heard about web services haven't you?"

John: "Yes, of course"

Didier: "Then imagine that the document produced by your application is in effect a mini hierarchical database. In this case we use XML to encode the data using a modeling vocabulary. We can say that we used XML to create a modeling language. Thus, another application can request your data packaged as an XML document.

"In the case that another application requests the database, your application provides the XML document without any transformation. If a rendering device requests the same document, then it can be transformed into the rendering format the device understands. You gained something here: the capability to provide the data encoded as a mini hierarchical database and as a rendering format. Thus, the script you created produces an XML document -- this can be considered a Web service.

"This whole process can be streamlined when rendering devices support a transformation language. In fact, it's likely that the mainstream browsers like Microsoft's IE and Mozilla will support XSLT before the middle of next year. When this is the case, your server won't have to perform any transformation, it will occur on the client side. The whole process has been partitioned between the server and the client."

John: "OK, I get it now!"

Of course, John could have argued that this involves too much processing on the server side. It does so because, today, no mass market browsers support a client side transformation language (compliant with W3C recommendations). However this is the argument we had against using Java over C, until we discovered that now a 1GHz processor can handle more work than the 266MHz CPU we had at the time we said that -- so, although there's a processing overhead, we can live with it in order to get the flexibility from using an intermediate XML document.

Also, when mass market browsers include a W3C-compliant XSLT engine, more processing will occur on the client side, and this will reduce the work done by the server. Or if a rendering device does not have the capabilities to support an XSLT engine, then a gateway or proxy can handle that task. Whatever the mechanism, the implication is that the processes to create the XML document and to transform it can be separated.

Think about web services. In this case, we divided the application into two services:

• The model creation service. This is what we called the web service. It creates a mini hierarchical database encoded in the XML format.
• The view transformation service. The service used to transform the model into a rendering format.

These services can be distributed over several machines if needed to balance the overall load. As we have observed the load could well be in the near future partitioned between the client and the server.