Community TV: Delphi 6 XML Data Bindings with Mark Edington

By: John Kaster

Abstract: John K talks with Mark Edington about XML Data Bindings and how support for XML DOM is implemented with Object Pascal language bindings. Includes MP3 audio and text transcript.

Community TV: Delphi 6 Launch Interviews

Delphi 6 XML Data Bindings with Mark Edington

R&D Engineer

Interview by John Kaster, Borland Developer Relations. Mark and John talk about XML Data Bindings, which provides language bindings for XML Documents and the Document Object Model (DOM). This support provides code insight and compile-time syntax checking for XML. Topics include Data Bindings, XML Schemas, and DTDs.

You can

  • view the streaming version (11:53),
  • download a zipped MOV (103MB)
  • listen to or download the MP3 audio (4MB)
  • Interview Transcript

    Special thanks to Deborah Pate, TeamB member, for her initial transcription of this interview.

    John Hi, this is John Kaster, with Borland Developer Relations. I have Mark Edington here with me today, an engineer on the Delphi 6 team. Hi, Mark!
    Mark Hi!
    John Mark, for this release you've been working a lot on XML document processing, and I heard you mention XML databinding. What exactly is that?

    An XML databinding is a way to create a language, a mapping, that ties into your XML data. If you want to think of an analogy, the closest thing that we have today would probably be something like a persistent field that you use on a TQuery or something like that in our existing technology, where by creating this component you're able to reference it specifically in your code. So, the databinding allows us to generate code that you can write using the standard, more or less property-based programming that we're all accustomed to in Delphi. For instance, if you have some customer information that's in an XML document, instead of writing code that traverses down into this XML hierarchy of nodes, and finding the customer's name and replacing it, you simply would write code that would look like what we're used to writing today in Delphi, which is

    Customer.Name := 'Mark';

    so it makes it a lot simpler. It brings RAD to XML document programming.

    John You were just talking about using a databinding to modify data in this XML document. That can be several levels deep, can't it?

    Yes, that's correct. In the databindings you'll have a hierarchy of the databindings that mirrors the hierarchy of the XML document itself. For instance, I gave the example of updating customer name. If that customer was part of a purchase order, for instance, then the code might look something like

    with PurchaseOrder do Customer.Name.Update

    or you could say


    So the hierarchy is managed the same way that we manage data structures in Delphi code. There's a one-to-one correspondence between the hierarchy in the document and the hierarchy in the databinding itself.

    John If I didn't want to use XML databindings, how much code would that take to do the same thing?
    Mark That's a good point. If we write the code using traditional, say, DOM-based programming to update the document, then we have to traverse down through. The code ends up looking pretty awkward quickly, because we'll say "iterate over the child nodes" or


    It gets awkward because, what you can do in one line of code with a databinding might take you eight lines of code if you were doing just straight DOM document programming.

    John So, I find this XML document that I've got to do some processing on — how do I create the databinding for it?

    We have a new wizard, which is part of Delphi, that basically takes as input either a standalone XML document (that's actually the data you want to manipulate) or a DTD (or some other type of schema) that you specify as the input. Then you'll be given another screen which will show you more or less the structure, in a treeview, of what the data looks like.

    At that point you can decide whether you want to create bindings for everything in the document or just certain things. You can change how types are mapped, whether a particular property is of type string, or integer, and whatnot. More often than not, probably, all the defaults will be fine. At that point you just proceed through to a final page which gives you a review of what's going to be created. Say "Finish," and boom! You have a unit now that's part of your project that you use to manipulate the data.

    At that point there'll be a function that you call that gives you a databinding that becomes the root of the document that you do processing with.

    John This wizard, what kind of code, exactly, does it generate?
    Mark What we'll generate is a set of interfaces which correspond to the data structures as they exist in the XML document, and the corresponding classes which implement those interfaces. The classes basically map onto an underlying DOM implementation, so there's never any caching of the data that occurs. If you request the value of, say, the customer's name, it'll read the value directly out of the DOM. That's what the unit will contain. Depending on how complex the structure is, it'll contain one or more interfaces and a corresponding class that implements each one of those things.
    John And the "DOM" is? What does that stand for?
    Mark DOM is the Document Object Model. That's probably the most commonly used mechanism today for doing XML document programming, if you will. If you need to create a document from scratch, you'll typically use the DOM. There are also other technologies for creating documents (you could just build them up with strings), but the DOM is the most common that's being used today.
    John Once I've run this databinding wizard, my source code would know what the XML document is supposed to contain?

    Right. That's called early binding, and it allows us to leverage the CodeInsightTM feature of the compiler. If you have something you need to update, and you type something like the example I gave earlier,


    at the point you hit the period, you'll get a list with the CodeInsight of all the structures that are valid at that point. You'd see something like


    Then you'd press another dot and see

    Name, Street, whatever.

    John So I'd hardly ever need to refer to my XML document again?
    Mark No, for the most part you should be able to keep tabs on what the structure is by simply using the CodeInsight feature. That's definitely one of the big advantages of using the databindings.
    John Everybody's talking about XML now. I think even my grandmother's heard of XML, so there are going to be tons of XML documents all over the place. How am I going to know when I should use a databinding on it and when I shouldn't?

    The main determining factor in when a databinding is going to be useful is whether or not you know about the structure ahead of time (because you have to have some type of structure in your document), and whether or not it's going to be something that conforms to a DTD (or some other type of schema). When it conforms to a DTD, the databinding actually serves the purpose of enforcing the structure of the DTD. Unless you go outside the scope of the databinding (which is possible through the architecture), if you stick to using the properties and the other structures that are generated, you'll always be conforming to the DTD. It's enforced by the nature of the interfaces that are created.

    Probably one of the best examples of a databinding that people will be able to look at in Delphi is the databinding we created for XML Schema, which is the emerging standard for defining structure in XML documents. Over time it will slowly replace DTDs. That databinding is quite complex because XML Schema is quite complex. If you had to go out today and create an XML schema for one of your documents, you'd be hard pressed to do that starting from ground zero because XML Schema is a very complex specification which includes numerous details.

    What this databinding does is make it very simple to create a new XML schema, for instance. Say you're going to create a new type. You can do something like


    You've now created a type. Then, with a reference to it, you can say


    and those correspond to properties that are on the bindings. In that way it's a very natural, simple way of programming your document.

    Likewise, if you want to read the data that's in a schema, you can say, "Give me a list of all the elements that are in the schema," which is something the databinding wizard needs to do, so that [you] can know what properties [you] need to generate. There's a simple method that you can call to give you a list of all the elements.

    Now, if you had to write code using the DOM, as I mentioned earlier, to go out and get that same information might require 50 or 100 lines of code, and intimate knowledge of XML schema and structure. By using the databinding, you hide all the complexity of XML Schema.

    That's kind of a plug for the XML Schema databinding, which really goes beyond what you can do with the wizard. Still, it is a databinding, and it's a good example of what you can do with that kind of technology to simplify the programming tasks that people are faced with.

    John You just mentioned DTD. What does that stand for?
    Mark Document Type Definition. It's been the standard way for defining what an XML document can contain for most of XML's life. In fact, part of the XML 1.0 specification is where DTDs are defined. Unfortunately, it has a number of limitations, so it's being slowly phased out by other technologies, not the least of which is the XML Schema specification which was actually just finalized recently.
    John What do you do in the case when you don't know what the format of the XML is going to be?

    Well, In that case, you can fall back to the TXMLDocument, which is actually the underpinnings of the XML databindings. Everything is based on TXMLDocument and the primary interface which is used in there, called IXMLNode. In that case, it's a component you drop on the form and point it at an XML document. Set Active to True, and at that point, you can begin iterating over the data.

    The hierarchical data will be represented in a childnode list that you can iterate over. If you need, for instance, to display it in a treeview, you would just write a recursive algorithm to copy the data out of the document and into the treeview. You could search through the document using that [method]. It's more like the DOM programming model, and it's not as RAD as the databinding programming model.

    John You just mentioned DOM again. Do we have support for actually programming in DOM?

    Yes, absolutely. One of the things that we've done solves a [common] problem that people have today. As I mentioned, most XML document programming is probably done with DOM today. [People] tie themselves more often than not to a particular vendor's implementation because, although the DOM specification (which comes from the w3c) defines a set of interfaces for manipulating XML data, there are certain parts of it, such as saving a file to disk or loading a file from disk, that aren't part of the specification. Those are left up to individual vendors, who implement a DOM, to decide how to do it.

    It's difficult today to write code which will read an XML document that works on Windows and also works on Linux. One of the things we've done to address that problem is, we've taken the interfaces that are actually defined by the w3c, that do the DOM Level 2 specification, and we abstracted out those that are independent of any vendors. They exist in a unit called xmldom.

    There's a registration mechanism in place there. For any given vendor (for instance, Microsoft), you can create a unit which maps their implementation into the actual w3c specification. Thereby, it's cross-platform. If you were going to take that same program and bring it over to Linux, you would just simply use a different DOM vendor that's available on that platform.

    John Well, that was really interesting. Thanks a lot for your time, Mark.
    Mark Thank you!
    John And thank you for watching.

    Transcript produced by White Tiger Communications

    Legal Notices

    These multimedia files are copyright © 2001 by Borland Software Corporation. All Rights Reserved Worldwide

    All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation, formerly known as Inprise Corporation, in the United States and other countries. Other names mentioned herein may be trademarks of the party using such names. This release contains forward-looking statements. All statements that are not historical are forward-looking. Forward-looking statements may relate to, but are not limited to, Borland's future financial performance, capital expenditures, revenues, acquisitions, earnings, costs, product development plans, global expansion plans, estimated size of potential customer markets, demand for our products, the projected acceptance by existing or potential customers of new technologies and the potential features of, or benefits to be derived from, the products developed, marketed or sold by Borland, market and technological trends in the software industry and various economic and business trends. Such forward-looking statements are only predictions and involve a number of uncertainties and risks that may cause actual events or results to differ materially. Factors that could cause actual events or results to differ materially include, among others, the following: general economic factors and capital market conditions, general industry trends and the potential effects on us of competition in computer software product and services markets, growth rates in the software and professional services markets that we participate in, rapid technological change that can adversely affect the demand for our products, shifts in customer demand, market acceptance of new or enhanced products or services developed, marketed or sold by us, delays in scheduled product availability dates, actions or announcements by our competitors, software errors, reduction in sales to or loss of any significant customers, our ability to successfully integrate acquisitions, any failure by us to protect our intellectual property rights, the dependence of certain of our business units on licenses from third parties, our ability to attract and retain qualified personnel, and other factors described in our latest Annual Report on Form 10-K and our latest Quarterly Report on Form 10-Q filed by Borland Software Corporation with the SEC, copies of which may be obtained from the SEC at Borland undertakes no obligation to update any information contained in this release.

    Server Response from: ETNASC03