Slashdot Mirror
Effective XML
In Effective XML: 50 Specific Ways to Improve Your XML, Elliotte Rusty Harold takes a different approach: know your elements and tags -- they are not the same thing! -- and weigh your choices in a context, because any technology applied for the wrong reasons may fail to deliver on its promises.
Following Scott Myers' groundbreaking Effective C++, the author invites us to re-evaluate seemingly trivial issues to discover that life is not as simple as it seems in the world of XML. In each of the 50 items (chapters), he gets into the inner workings of the language, its usage and related standards, thus giving us specific advice on how to use XML correctly and efficiently. The 300-page book is divided into four parts: Syntax, Structure, Semantics, and Implementation. Yet in the introduction, the author sets the tone by discussing such fundamental issues as "Element versus Tag," "Children versus Child Elements versus Content," "Text versus Character Data versus Markup," etc. On these first pages the author started earning my trust and admiration for his knowledge and ability to get right to the point in a clear and simple language.
The first part, Syntax, contains items covering issues related to the microstructure of the language, and best practices in writing legible,maintainable, and extensible XML documents. (In it, over 19 pages are dedicated to the implications of the XML declaration!) That seems a lot for one XML statement that most people cut-and-paste at the top of their XML documents without giving it much thought, doesn't it? Actually not, if you follow the author's reasoning and examples.
The second part, Structure, discusses issues that arise when creating data representation in XML, i.e. mapping real-world information into trees, elements, and attributes of an XML document; it also talks about tools and techniques for designing and documenting namespaces and schemas.
The third part, Semantics, explains the best ways to convert structural information represented in XML documents into the data with its semantics. It teaches us how to choose the appropriate API and tools for different types of processing to achieve the best effect. This chapter has a lot of good advice for creating solutions that are simple, effective, and robust.
The final part, Implementation, advises the reader on design and integration issues related to the utilization of XML; these issues include data integrity, verification, compression, authentication, caching, etc.
This book will be useful to a professional with any level of experience. It may be used as a tutorial and read from the cover to cover, or one can enjoy reading selected items, depending on the experience and taste. The book's very detailed index makes it an excellent reference on the subject as well. In the prefix to the book, the author writes, "Learning the fundamentals of XML might take a programmer a week. Learning how to use XML effectively might take a lifetime." I'm not sure about the "lifetime" -- that's an awfully long time for using one technology -- but for the most confident of us this still may not be enough :) . Your mileage may vary, but I suspect that you could shave a few months off that time by browsing through this book once in a while. Most importantly, it will make you a better professional and make you proud of the results of your work. Wouldn't this worth your while?
You can purchase Effective XML: 50 Specific Ways to Improve Your XML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
If you want to read any book for free, just ask your local library to order it and they will. Libraries guess at what books people want to read, so if anyone shows any interest in any book, they order it. They loose their federal funding if they don't spend the money they are allocated, so they are generally VERY willing to buy as much as possible.
----
Squirrel
Sure, XML isn't inherently that deep - but neither are the tab-separated ASCII files which Unix tools used to do all kinds of really powerful things. Similarly, LISP property lists aren't that complex. XML's a bit more flexible, and carries enough decoration with it that people are willing to use it for building interfaces that they might not build using ASCII or XDR. And anything that lets the EDI people replace their stuff with simpler, more open technology is good too..
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
XML would work better if there were consistent DTDs for tagging information that everyone would use. There should be an open database of these DTDS.
I was looking for a simple one to tag photos with. Couldn't find it, made my own. Is there a repository of these DTDs out there?
One of the things that I have found limiting about XML is that it is inheirently hierarchical. Real "things" can be categorized many ways. Hierarchical classification systems (such as our modern file systems) work poorly to classify a broad scope of information. Thus, some of the new development in the FS in Longhorn and also some I've head about, but can't remember, for Linux.
There are only 6,863,795,529 types of people in the world.
I share your opinion regarding XML, and have yet to find a great reason to use it, other than feeding data to our vendors systems through their proprietary file layouts.
On that note though, I wonder if this author has some insight into better uses for XML than what I've typically seen (XML does everything!). I won't, however, be running out to buy it, as XML will always be just more bloat and a resource hog by nature.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
I have not read this book, but it sounds interesting already.
XML is an interesting technology that has the potential for changing the way we use technology in all kinds of weird and wonderful ways. (And in a few ways that may not be so wonderful.) But using XML correctly is tough. I've written and discarded more DTDs and schemata than I care to admit because they were seriously flawed. Getting it right is important and very, very hard.
XML looks simple, and in some ways it is. But in so many other ways it is not simple at all - in large part because it gives us a tool to approach some very hard problems. And hard problems, often even when expressed in the simplest way around, tend to stay hard. (Calculus makes saying some things simple, for example, but understanding those things still takes work and insight.)
I will be taking a good look at this book in the near future to see what it has to say. And I'd urge those who dislike XML to do the same. And finally, even those who like XML need to think hard about how to use it well, so perhaps this would be a good read for them too.
Others have said it before, but I'll say it again. XML is heavy weight and isn't free.
XML needs to be updated to allow binary encoding. The open-source high-performance parser/generator library at the link demonstrates the performance gain.
Reading through the posts on this board, I tend to agree with the criticisms about XML. It's a big dreadnought of a specification when, in most cases, a nice light corsair or even single-seat fighter would do the trick. Still, I would normally be inclined to say of XML what is said about Democracy: it's the worst system out there, except for all the others.
Then I found YAML. Long and short, YAML is very lightweight, eminently readable, easy to use (parsers exist in multiple languages) and a pleasure all kinds of projects that require data serialization. Where XML branches off into other types of uses, like XSL programming, YAML doesn't really compete. I find this to be a strength, actually, because once you've used YAML and seen it in action, XSL seems like a big, fat add-on. But for those that rely on XSL and other things, YAML won't do the trick.
But if all you need is data serialization in a compact, easy-to-read, easy-to-use package -- and this, in my opinion, is by far what XML is most used for -- then YAML is great. Give it a shot.
As for XML. I used to hate it with a passion. Now I still hate it, but I'm less passionate. The creators of XML are ambitious people, and they tried to do something in that spirit. It works, basically and XML doesn't deserve *all* the bad press it gets.
Chr0m0Dr0m!C
You bring up some really good points. The reason that you hear a lot of "XML is slow" is because of the usage of XPATH. To use XPATH expressions, most implementations parse the entire XML document into memory.
I suppose you *could* write a custom parser. If your structure is well-defined, and not subject to a lot of changes, you could significantly increase performance that way. The other option is to parse the document once, get out what you need to get out into smaller chunks, dump the larger document, and only work off the smaller chunks.
Looks like TMTOWTDI is not just for Perl
Random Musings
I saw a Microsoft demo that was supposed to show how powerful and useful it could be to insert XML-tags into Word documents. The idea was to fill the Word document with useful information (just fill in the users name here, and all information about the user is automatically inserted, now how good isnt that?). MS calls this Smart Document.
.dll-file.
.dll-file that conforms to Word interfaces (that MS of course will have debugged and patched in about two years, and then they'll obsolete it by releasing a new version), then writing something that GENERATES a Word document and gives it to the user makes much more sense to me...
So, I took a look in the XML-file that the connected to the Word document to make it smart. I wasnt very impressed (but fairly amused) when I saw that the XML-file was like 30 lines of blahah, and in the middle of it I found a reference to a
If I need to write a
And in any case, XML has nothing to do with it... they could of course have created "tag" functionality in Word without using XML.
"2) XSLT
Have you tried it? I rest my case."
Yes and I wouldn't rest my case on that statement if I were you.
I've been working with XSLT professionally (for big clients including 3M) for 3 years, building the top tier in 3 tier architectures and have no problems working with it. It makes perfect sense for what it is: a solution for turning XML into something else, whether another XML document, another XSLT stylesheet (which I'll admit can be a brainbending exercise), HTML or plain formatted ASCII. In places where multiple presentations will exist for a given dataset or the presentation will change due to constantly redefined presentation requirements (ahem marketing ahem), XSLT gives you the flexibility to just keep building the same XML documents in your app and make them look like they're supposed to with different XSLT.
<shamelessplug>
Incidentally, I'm looking for a web development contract in St. Paul/Minneapolis if anyone's looking for an XSLT expert (or PHP or any of my other areas of expertise) who actually knows how to solve real problems. Email me for more info.
</shamelessplug>
The Glass is Too Big: My Take on Things
Well, duh, if you are using XML for non-heirarchical data, then your using it wrong.
.. NAME=".." ADDRESS=".." AGE = ".."/> .. NAME=".." ADDRESS=".." AGE = ".."/> .. NAME=".." ADDRESS=".." AGE = ".."/> .. NAME=".." ADDRESS=".." AGE = ".."/>
/. The same folks who insist that obscure languages like Haskell, Dylan or Eifel are "better than ${your language here} why doesn't anybody else use it". will still insist on transmitting and storing data in language and platform dependant binary files or in non-self describing data structures such as:
..\t..\t..
..\t..\t..
..\t..\t..
On the other hand if it looked more like this:
<Records>
<RECORD id =
<RECORD id =
<RECORD id =
<RECORD id =
</Records>
and if the tag was nested in something else, then xml is appropriate.
At the risk of sounding trite "right tool for the job".
I am currently working on an EDI application where the highly structured and hierarchical nature of our data makes it perfect for xml. Add in good tools and searching capabilities (Like XSLT for transforming the raw structure to something else or XPath for searching it) and you have a very powerful data exchange that is platform and language neutral.
But just as you wouldn't use VB to program kernel modules or device drivers, you wouldn't (and shouldn't) use XML for everything, just because it's cool and new.
I am always amazed by the XML luddites on
As for it not being efficient, well that really depends on what you mean by efficient. If you mean that it is slow to read, then you have chosen the wrong parser. Not a fault of the markup itself. Perhaps the design of your document is inefficient. But If you want a way to efficiently exchange self-describing data between applications written on different plaforms in different languages, then use XML.
Or come up with something better.
Never by hatred has hatred been appeased, only by kindness - the Buddha
Bandwidth is an order of magnitude more limiting than tree parsing, egg. That and the facilities the tool vendors decorate their stuff with. Of course its not free, what is?
SQLXML and most other value-adds are bull. Your business objects should optimize the hell out of their DB access and return XML. XML is messaging and presentation tier glue. Read the book.
illegitimii non ingravare
That's because everyone uses slow XML parsers. Some years ago at one of the then-top 5 web portals I was unhappy with the standard SAX/DOM parser in use; it was ridiculously slow (and buggy).
So I wrote a new one. Parsing XML became one hundred fold faster! I timed it quite carefully.
Other people in this thread are saying "of course XML is slower than binary formats, it's 3 times bigger." But a factor of 3 in performance is nothing, considering some of the advantages.
A slowdown of 100, on the other hand, is absurd.
I don't know why people don't rebel against this and make faster XML parsers the widely-used ones; for whatever reason, apparently everyone continues using slow parsers.
At any rate, no, XML is not slow. It's just a simple, easy to parse format, for which IBM and others have written very, very slow parsers.
And everyone just assumes that it has to be slow. Sheesh, why should an XML parser be slower than a C++ compiler??? Come on.
Professional Wild-Eyed Visionary
This is by no means assured. When you store data in a binary format, you generally have to have code to deal with byte-swapping and other format conversions. Also, generally speaking, the limitation on character parsing is memory bandwidth - if you are using a modern CPU, it is going to spend most of its time waiting for bits to come out of memory, and it doesn't care whether they're an ASCII (or utf8) byte stream or binary words.
Also, a lot of stuff that goes around in packets is free-form text anyway, not binary data. So in the case where you're just passing numbers around, yes, XML is going to be a bit slower simply because there are more bits to pull out of the buffer. But in the case of plain text, the difference is probably not going to be very significant. In cases where it is significant, you probably don't want to use XML.
You are right that XML is not a panacea - I wouldn't use it for every application. I think a lot of the anti-xml rhetoric we hear is because so many people do use it for the wrong applications, and then other people see what they've done and start retching.
A couple more points - XML::Twig allows you to parse XML in PERL without sucking the whole file in at once. Also, the article to which I was replying was talking about SQLXML, which I presume is already plain text. It's tough to imagine that XML is really going to make that significantly slower - if it is, it's probably because of a poor implementation, not increased data size.
Recently I was developing a pseudo file system and was using xml to store the metadata (ie date, name, link references, permissions, etc.). The chief advantage of using xml was that the data files were text and could be readly edited and read. However they need to be accessed often and performance was a dog. My boss saw what I was doing and recommended I use perl syntax to represent the hierarchal data and use Data::Dumper and Safe::rdo. I did and performance improved several times while still retaining the advantages of text. For example (using a nominal order record) instead of
...
...
...
<order>
<customer>
<name>
<fname>Bill</fname>
<lname>Brune</lname>
</name>
</name>
<customer>
</order>
<manifest>
&nbs p; <item>
<id>209</id>
<title>Grapes of Wrath</title>
<qnt>1</qnt>
<unit_price>$10.75</unit_price>
  ; </item>
...
would look something like ( compacted to avoid the lameness filter).
order => {
customer => {
fname=>'Bill'
lname=>'Brune'
manifest => [ { id=>1,
title=>'Grapes wrath',
qnt=>1
unit_price=>$10.75
},
{
}
The added advantage is that you can also add code to such as
{ 'timestamp'=> scalar localtime,
'pid'=> getppid,
...
}