XML versus Data Binding
Comparing XML with Object Oriented and Procedural Languages
The xml languages ( xslt, xml schema, xquery, etc) are declarative, i.e. descriptive not prescriptive. Conversely, java, c++, python, php, etc are object oriented and procedural, i.e. prescriptive not descriptive).
Many tools have been created to map (bind) the data and datatypes in xml to data structures and datatypes in object oriented and procedural languages and vice versa. This is called data binding.
Use One Data/Processing Model or Two?
One Model: Some people advocate doing all processing using the xml languages. For example, transport the data as xml, then validate it against an xml schema and then process it using xslt and xquery.
Two (or more) Models: Some people advocate using a combination of xml and object oriented and/or procedural languages. For example, transport the data as xml, then use data binding to map it into data structures, and then do all the processing using one or more object oriented and/or procedural languages.
Advantages of One Data/Processing Model (XML)
The mapping from xml to data structures in object oriented and procedural languages is not governed by standards. For example, the xml schema specification does not tell you how its datatypes map to java or c++. Consequently, some of the data binding tools are incomplete and do not map cleanly.
Doing a mapping from xml to object oriented/procedural or vice versa typically involves lots of api calls and lots of programming. Thus, rather than spending your time writing code to solve the problem you're supposed to be solving, you spend a significant amount of your programming effort converting from one system to another. That's not efficient.
When the xml changes (e.g. the xml schema changes) then the data structures in your object oriented and procedural code must change. This can be very difficult and time consuming.
Having two different models of the same data, understanding how they relate, and organizing yourself to keep them in sync is adding complexity above and beyond the complexity of solving the problem you're supposed to be solving.
Dimitre Novatchev wrote:
My personal observations quite support ... statements about how much additional resources are needed if data has to be converted from xml to and fro an object representation. 70% - 80% of the whole construction work can go into this activity. After recently finishing such kind of work I had the feeling that had I decided to use only a single, xml representation, I would have achieved the results in 3 to 4 times less time.
The format used for data interchange (xml) is primary in the sense that it needs to be agreed with other parties, so it makes sense to also use that as the primary format for processing.
Sticking with the xml languages provides ease-of-use benefits. For example, several years ago I did an experiment: I wrote some xslt to solve a problem and then solved the same problem using java. It took me 10 lines of xslt and over 100 lines of java. Not a lot can be gleamed from a single experiment, but all my experiences since that time reinforces this experiment.
Note: sticking with the xml family of technologies does not mean that object oriented and procedural languages are no longer used. Rather, they are pushed to a lower level. For example, an xml schema validator may be implemented in java or c++. An xslt processor may be implemented in java or C++. So you - the programmer - work at the xml level, and underneath the xml processing are tools, written in object oriented and procedural languages, that carry out the processing.
Advantages of Using Two (or more) Data/Processing Models
Some programmers are more comfortable working with data structures than working in functional languages such as xslt.
Swedish Translation: Daniela Milton has translated this article into Swedish; it can be found at this URL: http://www.autoteilexxl.de/edu/?p=1404 (thanks Daniela!).
Thanks to the following people for their input to this document:
- Roger Costello
- Dave Czulada
- Mukul Gandhi
- Rick Jelliffe
- Michael Kay
- Robert Koberg
- Boris Kolpackov
- Jack Lindsey
- Dimitre Novatchev
- Bryan Rasmussen
- Dennis Sosnoski
Last Updated: November 27, 2014