Summary
In an IBM developerWorks article, O'Reilly author and editor Brett McLaughlin questions several of the common uses of XML in enterprise applications, and invites his readers to ponder what XML is really good for.
Advertisement
In books such as O'Reilly's Java and XML (now in its third edition) and Java and XML Data Binding (2002), Brett McLaughlin has already offered plenty of advice on how to use XML in enterprise Java applications. Now McLaughlin is asking his readers to ponder not how to use XML, but why to use it.
In What's XML really good for?, published on IBM's developerWorks site, McLaughlin points out that XML has been around long enough to no longer be a technology that developers use just because it's in vogue. Instead, developers should think hard about the areas of an enterprise application where XML is a good fit—and possibly avoid using XML when other technologies could provide simpler solutions:
The jury is still out on XML's "killer application"—the ultimate usage of the data format that seems to justify its creation. As you look at some of the most common usages in this article, you'll quickly see that even experts disagree, and XML can be used—or not used—in lots of different applications.
McLaughlin looks specifically at two areas where XML is commonly used: As a configuration file format, and as a data interchange format. In both cases, simpler solutions would often suffice, according to McLaughlin.
Where do you think XML is really a good fit in an enterprise application?
Data, and describing data obviously. I believe its met its goal very well. I think a lot of people find fault with it, or constantly look towards alternatives, because it's not the easiest technology to integrate with in terms of programming language. Is this another impedance mismatch similar to the OO/R issue? Maybe.
In terms of speed, parsing and processing, I suppose that might be a major concern at some point if you deal with a lot of data, but if it's a really strong concern, I can see reverting to a CSV-ish mechanism for bare minimum wasted on data structure.
To me, What's really the draw to an alternative format like JSON? It's neither as well positioned as xml, nor does it offer the minimalism of a csv. It seems like "eval" is it. "I can just eval within my dynamic language".
XML can be validated, it is easily readable, the tools are setup, I'm very happy with it.
After all this time, it still amazes me that folks *still* say that XML is "self-describing". Only a little bit, and only if you speak the (human) language it is written in.
So, what does this mean:
<asdlkfj> kkkkkk </asdlkfj>
And how is it to be processed? Whatever you say; I say you're wrong, I will make it so.
And even then, you still need to; get a parser, parse, and write YourProgram to act on the data. XML files do none of those things. As McLaughlin tip-toes around: YourProgram is all you need (and a simpler one at that) if you use properties or csv data files.
A RDBMS catalog is meta-data. Gad.
People, GML is from IBM reporting utilities of the 1960s. The only difference is angle brackets. troff and nroff derive from the same.
If you intend to print a document with Italic here and WingDing there, then any of these techniques are useful. But for nothing else.
It is easily better than all the alternatives for transferring geographic information (between different applications, organisations). The structure is useful here and also the character encoding. Most of the alternatives have problems with characters that don't fit in a single byte (and/or don't declare the character set used within the data, instead relying on passing that on a separate scrap of paper).
It seems that most people cannot get over the fact that XML is verbose. So what? It does not stop me from doing interesting things with it. It has namespace support, it has SAX, it has DOM, both of which are well known standards, it has XPath, it has extensive editor support, it has DTD/XSD, it is simple to read (verbose, but simple), it is understood by a large amount of people, and most important of all, it is supported in virtually all environments. What more do you want? Give me a data format that has all these features and then I will switch! Until then, I will suffer the verbosity of XML gladly.
Irrespective of whether it's the optimal solution for anything, XML has enabled a lot of things to happen that never happened before simply because it's good enough and it's common currency. Similarly, there might be better protocols than TCP/IP, but it doesn't matter anymore.
It is good for encoding data that is complex enough to require a context-free grammar to understand, but which is not so often hand-coded that it's worth applying compiler technology such as lex and yacc.
In other words, it's for situations in which the Interpreter design patter makes sense, but you're willing to put up with a somewhat ugly notation if it makes development easier.
> Data, and describing data obviously. I believe its met > its goal very well. I think a lot of people find fault > with it, or constantly look towards alternatives, because > it's not the easiest technology to integrate with in terms > of programming language. Is this another impedance > mismatch similar to the OO/R issue? Maybe.
It's not as hard as people make it out to be. I think the problem is that most (all?) OO languages cannot describe the complex structures possible in XML without executable code. This is the impedance mismatch. But viewed from a XML-centric perspective, the problem is easy because the OO structures are so simplistic. Transforming to them with a XML specific language like XSL is generally trivial.
In terms of the overall topic. I think XML is really good at describing data. It when people start defining complex languages within XML that I start to question the logic.
I just read the article. He doesn't really say much of anything. There's really very little difference between configuration and data transfer in terms of how the documents are used. They are both data. He doesn't even mention the use of XML to represent process logic (e.g. BPEL.)
Honestly, have you ever considered other structured data formats for storing or transmitting data? ("structured" excludes .ini files and property files) Specifically, have you ever compared XML against ASN.1, JSON/YAML, s-expr, XDR, etc? Aside from the fact that there are 300 XML libs for every platform, XML never provides any technical benefit. The reason is that it was designed as a Markup language (for text), not an Interchange language (for data).
For example, with XML, it's ambiguous if you should put a value in an attribute or as text content: <first-name value="Chuck"/> <first-name>Chuck</first-name>
The reason it's ambiguous is the designers didn't design it to be a data interchange language. As far as they were concerned, if you wanted "Chuck" to show up in the rendered text, you put it in as text content. If "Chuck" is just a property of the markup, you put it in as an attribute.
With a data interchange file, there is no rendered text, which is where the ambiguity comes from. (i.e., you're trying to do WHAT with my markup language?)
> > Ummm... this is a wild guess, but I'd say that XML is > > really good at marking up text documents. Hence the > term, > > Markup Language. > > And a 'head-shop' is a place where heads are sold.
Michaels comment sounded a bit simplistic but was exactly my thinking. XML syntax is good for what it was originally created. XML comes from SGML which comes from GML and its purpose was:
GML simplifies the description of a document in terms of its format, organization structure and content parts and their relationship, and other properties. GML markup (or tags) describe such parts as chapters, important sections, and less important sections (by specifying heading levels), paragraphs, lists, tables, and so forth. [http://en.wikipedia.org/wiki/Generalized_Markup_Language]
SGML was originally designed to enable the sharing of machine-readable documents in large projects in government, legal and the aerospace industry, which have to remain readable for several decades—a very long time in information technology. [http://en.wikipedia.org/wiki/SGML]
XML is for documents. Why everybody wants to stuff all data into text documents nowadays is beyond my comprehension.
Flat View: This topic has 81 replies
on 6 pages
[
123456
|
»
]
Previous Topic
