|Delphi Clinic||C++Builder Gate||Training & Consultancy||Delphi Notes Weblog||Dr.Bob's Webshop|
XML stands for eXtensible Markup Language. It's a subset of SGML, while HTML is an application of SGML. The difference between XML and HTML is the fact that for HTML a pre-defined set of syntax rules exists. An XML document needs to follow the general XML syntax rules, but the exact keywords (tags) that can be used in an XML document are up to the author of the document, and specified in something called the DTD (Document Type Definition). Together with a DTD, an XML document is said to be a self-describing document, and that's powerful indeed. And yes, an XML DTD for HTML documents probably exist as well. So, an XML document is just an ASCII file, and while anyone and anything can read it, in order to understand it, we should have access to the DTD file as well.
So, what's the advantage of XML then? Well, it's a simple file format that everyone and everything can read. Combined with the ability to define your own syntax rules in a DTD, we can put just about everything in XML. From books to webpages to databases to customer order forms and invoices to entire operating or file systems - it's like a Silver Bullet. It almost sounds like Java, doesn't it? And with Java I always had the idea that there was more written about Java then was written in Java.
When it comes to XML, most people seem to think that XML will be the Holy Grail of file formats. Everything will be XML, and XML will be the ultimate way of communicating. That certainly seemed to be the case at XML One Fall '99 in Santa Clara (early November 1999), which I attended as visitor as well as speaker. There were roughly three kind of people there. Speakers could be divided into Vendors or Consultants, and the biggest group were the Visitors; almost 400 were present. Vendor sessions (including some of the keynotes that I attended) usually were along the lines of "we have these tools that support XML - you need them!". Consultant sessions usually went along the lines "Your organisation needs to adapt XML now - and we can help you! (especially defining your DTDs, which seems to be an area where a lot of money is made currently)". The visitors all went like "XML is really important, we must do XML now" (and some already "did XML"). When I asked some of these people (speaker as well as visitor) about "Why XML?", they usually stared at me, and - after a few awkward silent moments - answered "because it's the future; everyone goes XML". Yes, but why go bananas about it? I can see the sense of having an intermediate file format or language for data transfer (the "Esperanto" of computers), which XML and DTD can provide. Especially with the open community on the internet, XML-support will be handy. But I doubt if "everything will become XML". Sure, one or two years from now most tools and applications will have some kind of "import/export to XML" feature, just like most today have an "export to HTML" feature of some sort. But that doesn't mean that everything goes HTML. Nor did everything go Java when this was predicted a few years ago (remember Corel's Java Office Suite?)
XML is a way to give structure to data and information that can be passed between one application to another (including inter-application communication between multiple tiers, like Delphi 5 InternetExpress offers). As such, it offers a standard format, independent of the communication protocol being used. This is also one of the reasons why XML will play an important role in Electronic Commerce EDI (Electronic Data Interchange) applications and situations. The fact that a DTD can be used to "define" (and check) the XML document itself means that - theoretically - everyone can talk to everyone and everything as long as proper XML/DTD is used. XML will also play a role in the Publishing world. While I don't see XML replacing HTML for creating webpages, XML can certainly be used to publish papers, books or reference material (the structured way in which an XML document is built-up will also have effect on cataloguing these publications). IMHO, however, that's a relative small market, especially compared to the hype that "everything will become XML [format]".
Personally, I think that the hype around XML shouldn't prevent us from seeing what XML can really mean for us, and our applications. A portable file format, useful as language for inter-application communication. Nothing more, but nothing less. And when it comes to support for XML, then it's good to know that IBM, Oracle, Sun, Microsoft and all the other big Vendors have numerous tools that we can buy that support XML Today. As it's good to know that even more Consultants are nearby to help us (and our organisation) to get ready for XML. But it's even better to know that we can write applications that utilise XML - with or without DTD - by ourselves, for example using Borland Delphi 5.
Delphi 5 InternetExpress makes use of XML to communicate between the Application Server (MIDAS DataSetProvider) and the Client, which is a Web Server in this case (XMLProvider - talks only to a WebBroker MidasPageProducer).
The XML that's being passed back and forth between the Application Server and the Web Server actually contains MIDAS data packets.
In previous versions of Delphi, this MIDAS packet was in a propriety file format, and now it's XML.
In theory, that is, since the MIDAS data packet does not come with a DTD, so for now the only applications (or tiers) that have a good chance of "understanding" these XML packets are written in Delphi 5 (or C++Builder 5, once that version ships).
In other words: while MIDAS Clients and Servers in Delphi 5 can now send packets in XML, this does not really benefit from one of the core benefits of XML. I still can't connect a PowerBuilder Client to a DataSetProvider, nor can Oracle8i produce XML capable of being used by an XMLBroker component. And in fact, even within Delphi 5 applications, the XML produced by the DataSetProvider seems to be usable only by an XMLBroker component, which in turn only talks to a MidasPageProducer. Between a DataSetProdiver and a "regular" ClientDataSet, the data is still passed in the old propriety (and undocumented) data format.
So, XML is hype and Delphi's support of XML is also hot air? Well, Delphi does support XML all right, but not in the way or manner where XML is at its best. And even the other area where Delphi supports XML - as part of the ADO components - is merely inherited from functionality that is already present in the ADO components (and believe it or not: the XML produced by an ADOTable is not the same as the XML produced by the DataSetProvider when connected to an ADOTable).
Delphi 5's support of XML gives us a good headstart.
We can create distributed applications where the different tiers can communicate between each other by sending XML back and forth.
And we can load and save MIDAS data packets in XML format.
To be used by MIDAS-aware applications only, for now.
But it's a start, and it's here.
And XML itself? Well, at least I hope to have shown that it certainly has potential to play an important role. We'll certainly see a growing use of XML, both inside and outside of Delphi...
For more recent information on Delphi for Win32 XML Programming, check out my Delphi 2010 XML, SOAP & Web Services courseware manual.