Inside XML
The Scoop People love it, but XML won't save the world. If properly applied, it will improve the transfer of information between different individuals, platforms, and programs. A language that describes languages, XML in the real world has spawned hundreds of applications. In Inside XML, Steven Holzner attempts to make sense of the basic principles and more popular implementations as things stand right now. What's to Like? Holzner's caught platform independence fever, and he imparts a healthy sense of respect for W3C standards to his readers. While the current state of XML handling, especially in web browsers, is mediocre at best, he varies platforms when possible. Though most examples use IE on Windows, the author occasionally examines offerings from Mozilla and IBM.
The book's strength is describing a technology. The first five chapters explore XML's essential concepts, including DTDs and schemas, in as good an explanation as you'll find anywhere. Later chapters cover XSL (used to format and to transform documents), XHTML (the successor to HTML), CSS (governing the presentation of XML and XHTML documents) and RDF and CDF (to describe available resources) in sufficient detail. The explanations here are good, with accurate information and plenty of examples.
Java programmers will appreciate the extended descriptions of the DOM and SAX parsing styles. Though the examples themselves are in Java, most concepts translate fairly well to other languages. JavaScript also gets some attention, mostly in the confines of IE5.
What's to Consider? Though the cover blurb claims otherwise, most programming examples use Java. Perl earns a brief 13-page treatment, while ASP and Java Servlets share just eight pages in the same chapter. Exotic languages like C and C++ are conspicuously absent. A detailed description of the DOM and SAX approaches would benefit everyone, not just Java hackers.This massive tome could have stood another round of editing. Many examples run up to a page and a half in length when only two to four lines have changed from the previous listing. Other material is arguably filler, such as four and a half pages of JavaScript events supported in IE, or fifteen pages detailing XML DOM objects and associated methods before giving a single example of DOM usage. The publisher could have cut between 100 and 200 pages, instead adding footnotes to authoritative sites.
Worse yet, the book's organization is questionable. After describing the basics of XML, it veers off into a 50-page JavaScript tutorial. Java soon suffers the same fate. These chapters break the flow of subjects, use no XML in their examples, and should be appendices. (They're decent, as far as tutorials go. They just don't belong in the middle of the book.) Readers will have difficulty finding useful reference material mixed in with tutorials.
English majors will also find Holzner's transitions awkward. Logical sections often conclude with a phrase such as "Now I will talk about the topic named in the heading immediately following this sentence." XML is not a serial radio cliffhanger, and most readers can find their way down the page by themselves. It occurs often enough to be distracting.
The Summary Besides the reservations above, most of the information is solid and usable. Inside XML is at its best when describing technologies instead of how to work with them. Uneven presentation hinders (not hobbles) the book, making it a better introduction than a definitive guide. Though falling short of its claims, cautious readers will learn plenty. Table of Contents- Essential XML
- Creating Well-Formed XML Documents
- Valid XML Documents: Creating Document Type Definitions
- DTDs: Entities and Attributes
- Creating XML Schemas
- Understanding JavaScript
- Handling XML Documents with JavaScript
- XML and Data Binding
- Cascading Style Sheets
- Understanding Java
- Java and the XML DOM
- Java and SAX
- XSL Transformations
- XSL Formatting Objects
- XLinks and XPointers
- Essential XHTML
- XHTML at Work
- Resource Description Framework and Channel Definition Format
- Vector Markup Language
- WML, ASP, JSP, Servlets, and Perl
- The XML 1.0 Specification
You can purchase this book at FatBrain.
The idea is that XML spares you the trouble of defining your own file format and managing all the grunt work of data files. It lets you use common parsing, validation, and document manipulation tools.
Hmmm.... let's try a little something here:
Funny... it still sounds right. now let's try: Spooky - sounds like a Microsoft press release. Now, for the grande finale: OK, well maybe that was pushing it just a little...________________________
Corporate Jenga: You take a blockhead from the bottom and you put him on top...
If you're using Java, then a properties file is a good alternative, but if your data gets too complex, (e.g. repeating fields), XML will be much simpler.
To me, the main advantage is the fact that it is both machine and human readable. An XML config file is normally instantly understandable and programming languages can manipulate it quite easily without having to worry about CR/LFs and the completely different formats in flat file databases.
Also, the new XML Schemas allow a fully self-documenting, detailed explanation of what the content of an XML document should contain. You could use a stylesheet to turn the Schemas into DocBook documentation if you so desired. Certainly better than going over your application, taking notes, and writing up the documentation.
To be honest, although all of here at Slashdot can think that XML hasn't had an effect. MS's .NET is going to be entirely XML based, which is a good thing as it will allow communication with their platform easily. Sun's released ONE, which is just a rebranding name against .NET for Java, but it works now and is being used now. GNOME uses XML heavily and why not? Anyone writing applications can easily read the config files and output of another application and know what to do with it.
Okay, I've ranted a bit here, sorry, but it isn't just the future, it's the present. Of course, in the UNIX world we'll continue to use flat files and standard non-object oriented databases, but when we want to talk with the rest of the world, we will have a method of doing so now that doesn't involve reverse-engineering and so is a lot quicker to develop.
Prior to XML, we had used our own text based markup language (surprisingly similar to XML except only two levels of hierarchy) since 1989. We (30 year OLTP designers and coders) found it *much easier* to design, develop, debug, comunicate about, and communicate with than prior fixed field non-text formats
List of Synergies in case of XML (and mostly true with our old approach) include:
I would also point out that I have used SAX in some cases and DOMs in another. I had no problem quickly using SAX for message-based uses. It may be harder when using all the features of XML, but not all are needed for most data interchange usages.
The only good weather is bad weather.
Of course you can't think of XML as some sort of godsend. It won't make your children's teeth straighter and whiter. It won't solve world hunger, and it won't create a tax law that is equally fair and acceptable to all.
It's just a markup language. It's only strengths lie in the fact that 1)it clearly and easily represents heirarchical data and 2)could become a standard way of representing data in many applications.
If XML finds its way into wide acceptance under certain industries(if it hasn't already), then its strength as a descriptive markup is perfectly valid. It will make business easier if you can unambiguously exchange information, rather than sifting through proprietary annotations or trying to convert a flat ASCII file into [proprietary language of your choice].
<rant>
I am sorry to see from the looks of the review that New Riders has gone the way of Sybex and Que, though. As far as books in "pop tech" go, you can usually go by this rule of thumb: thickness is inversely proportional to quality.
Take two examples: My O'Reilly XML(before the standard) pocketbook, and our Que "Mastering Javascript" Special edition. My O'Reilly book is a scant 107 (small) pages, yet has proven to be a completely invaluable reference. I wouldn't trade it for anything but the next edition of the same book. Back when I was trying to learn Javascript, that freaking Que book wasted more of my time than anything else I've ever read. By the time I needed to know about the syntax for multi-dimensional arrays you could just forget it.
</rant>
This is a manual virus. Copy it to your sig and help me spread!
People that explain XML carefully should be revered. These scholars are pointing the way to the future. WHO CARES if the book uses strange English. It is after all a technical document and should be as obfuscated as possible!
Quote from early car manual (Subaru 360) "if one wish to engage first gear, one is pleased to depress clutch." Who needs clarity in writing and loginc when gems such as this are produced. I'm awaiting my XML update to that great old car
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
Wrok wrote: Of course the key to XML is the Apache projects parser and transformer libs over at http://www.apache.org
Funnily enough I have been trying to use the Apache code (Xerces-C & Xalan) for 2 weeks with marginal success. It's a huge, sprawling library, abstracted to the point where you can't hope to do more than copy and paste the sample code. Clearly they've been having a lot of fun with the patterns book. E.g. before you even think about performing an XSLT transformation there are around 10 factory/liaison/environment objects that need to be set up, and without a deep knowledge of what each is, you've little choice but to just copy-and-pray.
Besides, there has to be something iffy about a library that has 3 implementations of a string class...
*sigh* oh for the days when slim, well-defined libraries were the norm.
Some say that the XML isn't even a real language, that in spite of its proclaimed extensibility, it is "fixed." But I think they're cultural elitists.
Applications for the XML