Inside XML 127
| Inside XML | |
| author | Steven Holzner |
| pages | 1102 |
| publisher | New Riders |
| rating | 7 |
| reviewer | chromatic |
| ISBN | 0-7357-1020-1 |
| summary | A detailed but uneven treatment of XML and related topics. |
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.
Re:When XML is useful (Score:1)
Re:Centralized ASN.1 vs. Decentralized XML Standar (Score:1)
I don't think that the top-down/bottom-up thing is correct. In the case of both XML and ASN.1, certain 'tags' are set aside for unregistered use (PRIVATE tags in ASN.1) and if you use any such tags you need to agree with the person with whom you are exchanging data what format you are using. No difference I can see except the aforementioned 'religious' point of view with respect to the CCITT/ITU/ISO.
The only (programmatic) advantage I can see that XML could have is that the data describes its own type. BER-encoded data doesn't - you need to know what kind of object to expect.
However, this has been hobbled in XML by exactly the lack of central control of namespace you mention....I have no idea whose 'Invoice' DTD to use to interpret this object...so I don't see this as a practical advantage.
Re:Old idea new format (Score:1)
Both can encode 'binary' data (is an integer binary? is a jpeg?), but with different levels of efficiency.
Simple tools exist to dump BER in a very xml-like human readable format *given the ASN.1 definition*. Granted they have been traditionally used for different purposes (XML more text oriented, ASN.1 more 'binary' oriented) but the featureset of the two encoding methods in very similar.
Re:Old idea new format (Score:1)
ASN.1 can be (and is) used to represent some very complex objects (an email message with lots of different header type, complicated address, with fourteen different types of attachment, lots of which are themselves structured messages...you get the idea).
I may be missing something in XML but I don't see that it gives you anything except a "wire protocol" as well. It is a way to serialise an object into a platform-independent format.
The design choices for the format are different (wordy...good for humans, bad for network transmission) but that seems to be the only difference, technically speaking. [Apart from the (important) fact that an XML object self-describes its type...but this doesn't seem to be that useful in practice because of namespace issues. ASN.1 data types in a given protocol generally deal with this by including some data early on which identifies how to interpret the rest. e.g. an LDAP operation has a 'type').
Re:Old idea new format (Score:1)
I believe that this seemingly-small point is a major reason why early IETF protocols were implemented more easily. It is just so easy to debug SMTP with telnet...debugging an X.400 connection is worlds more difficult.
However, I have been impressed by ASN.1 'pretty printing' tools which take some BER (and the definition of the ASN.1) and dump it out in a nice human-readable format. This takes away XML's main advantage I can see (apart from the fact that XML is popular and the way of the future that is
Re:Dead on topic!!! (Score:1)
The 'combination of the two' is what I was alluding to above. I guess that there should be an automatic way of taking an XML DTD and translating to an ASN.1 definition (and vice versa). This would then allow particular objects to be translated between XML and BER.
Would this be the best of all possible worlds?
Where's Python?? and other ramblings (Score:1)
I do work with XML for a living, but I use Python for my DOM/SAX work. Python 2.0 and 4Suite [4suite.org] are really the best for rapid XML programming. However, most of the documentation for DOM, SAX, and XSLT apply to all implentations . . . I can read the Java examples and can translate that into Python. Granted, they are pretty similiar languages, but this should work for plenty of other programmers working this into their language of choice.
It is fishy that C and C++ aren't really mentioned, but there really doesn't seem to be much out there for XML-type stuff. Maybe someone here will post the URL's for more info on that.
Off the Python topic, I just bought ORA's new "XML in a Nutshell". I haven't had a chance to put it through the trenches yet, but it seems to be the best general XML book out there. Which I am glad, because I want to retire Kay's "XSLT Programmer's Reference" in a hurry. What ORA did to sum-up XPATH and XSLT in 200 pages, it took Kay (no lie) 500 pages. And it's the exact same thing!!!!
Re:XSLT book (Score:1)
The funny thing is . . .XSLT isn't that hard, once you figure out that how XSLT works with the document. That "how" is very important. Unfortunately, there isn't much out there, bookwise, about XSLT. I would try XSLT: Working with XML and HTML by Fung. Of course, that book wasn't out yet when I needed to bone-up on XSLT, so I had to use the other book that's out - XSLT Programmer's Reference by Michael Kay. It's way, way too detailed to get up and running fast on. And I still hate wading through it to look up something. Also, ORA's new XML in a Nutshell seems to have some promise in a reference for all things XML.
Re:xml (Score:1)
KEY1="value1"
KEY2="value2"
works fine for me. Why XML?
Geoff
Re:One thing bothers me... (Score:1)
Let's face it, not many people are bloody minded enough to write a C or C++ CGI app to produce web pages. OK, it used to happen, but nowadays there are much better alternatives (eg. PERL, PHP, JavaScript).
I like using C and C++, but to corrupt a famous phrase "a language has to know its limitations", and C is not the most friendly text processing language in the world.
Re:One thing bothers me... (Score:1)
Yes, but I wasn't sure whether the reviewers or the commenters tongue was in his/her/each others cheek!
Isn't this on HBO? (Score:1)
Oh, and where's the chapter on the cheerleaders?????
Clean up the grammar. (Score:1)
For example the phrase "(and plenty of uses both front-and-center and behind-the-scenes later)" is damn near impenetrible. As for "How well it succeeds?", well that is best left alone.
-Shieldwolf
Re:XSLT book (Score:1)
Re:XSLT book (Score:1)
Xerces is a sweet little library. Xalan is one big honking mess. I can't believe some of the same people wrote both. I hope TrAX will insulate people from all of that nonsense.
--
Bush's assertion: there ought to be limits to freedom
Re:Old idea new format (Score:1)
What I mean by that is that XML doesn't represent low-level binary data well. ASN.1 would allow you to represent binary data more easily into an XML document. It is of course platformless (endian-ness/ size of primitives).
I took a look at it when I was working at a telecoms company, but they still believe ATM is the next big thing!
I like XML a lot, and have been using XERCES-J to write a source control system. The human readable feature makes XML invaluable.
Re:Show me the SGML ! (Score:1)
Re:Did Vince McMahon just buy the XML? (Score:1)
Re:Cool, but not trivial (Score:1)
I thought it was only the whitespace and well-formedness that was different.
-Back to the drawing board.
(Has anyone else noticed their HTML is well-formed since they started using XML?)
Re:Of course no C/C++ (Score:1)
If I start using xmlpp and then find that Xerces C++ is faster, better maintained, or has better standards support, can I alter my codebase simply and easily. The answer is 'no.' I would have to go into each and every file, change the class/struct name (or use typedef or #DEFINE ugliness) and change any variation in the function calling conventions or parameters. This may involve completely reworking underlying design decisions for the entire codebase.
However on Python or Java, for example, I have a static set of interfaces that come directly from the W3C (the Java package org.w3c.dom for example) that would be used in my program. XML parsers in Java that implement this set of interfaces have only their document loading as parser specific. And Sun's JAXP package makes that a non-issue as well.
Restated: There is no common API for XML in C/C++. There are multiple parsers, but no common set of interfaces. Period.
Of course no C/C++ (Score:1)
Especially when Sun's Java API for XML Parsing is brought into the mix, you have a realistic way of completely abstracting the parser in current use.
Why is this important? No parser is perfect. Some have a better memory footprint while others are pure speed demons. No to mention the possibility of a dark horse in the future that blows everything else away (XML Schema or database interaction anyone?).
As long as this common API is missing in C/C++, where the only thing necessary to update code is a relink (or no relink in the case of COM), C/C++ will continue to be overlooked by the XML community and its requisite publishing contingent.
Re:XML not being the "do-all" (Score:1)
Re:XML (Score:1)
<foo><bar></foo>
parses as
(foo (bar)) or (foo)(bar)(foo)
unless you know the DTD. In XML you can. There are lots of other cases like this. Being able to find the structure without knowing the DTD is useful for the same reasons that Lisp's READ function is useful.
I think XML is hopeless, but it's *much less* hopeless than SGML, which was completely losing.
Re:XML? SOAP? DOM? Bloat? (Score:1)
(:foo ((:a
to
<foo><a x='1'>data</a></foo>
and only slightly less trivial to convert back.
Lisp people tend to get a bit bitter about the reinvention of something they've known about for more than 40 years, but then we like to be bitter.
As for using Lisp/scheme syntax for doing RPC-type things: yes, we do that too, it works pretty well.
Re:XML? SOAP? DOM? Bloat? (Score:1)
Lisp's 40th anniversary was 1998, the only older language in general use is FORTRAN. Of course there has abeen some (quite a lot!) of development over the 43 years.
21 Days.. (Score:1)
The book is a bit too aggressive with the introduction for true beginners, but I hope that once I get through it, the rest of the books will make the introduction clearer. It's a big undertaking.
--
Wouldn't Buy It Again (Score:1)
The author spends far too much time bashing MS on the one hand and then grudgingly acknowledging that IE has the best XML parser available. I'm no MS fanboy, but the hypocrisy made me sick.
A lot of the content of this book is just repeated drivel. Things like "Here, I'm including an element for item price" [insert simple XML example] "And here, I'm adding the item part number" [insert simple XML example plus one line]
Bah, sorry to go off on a rant, but save your money and learn this stuff online, or find another book.
Re:Learn XML. (Score:1)
Re:XML is just a descriptive markup (Score:1)
Re:XML is just a descriptive markup (Score:1)
But you use XML in your own post: see the <rant> tags?
</irony>
One thing bothers me... (Score:1)
-Andy
--
Re:XML is just a descriptive markup (Score:1)
inserting is inserting (Score:1)
Now try adding a field/tag to an xml file. Older programs will ignore it, and new ones can use it. <<
Inserting *anything* into the middle of a flat file is a pain in the butt unless you parse it first.
BTW, what are other file formats out there:
SDF, EDI (Edifact, and something else), DIF
any more?
protocol versus representation (Score:1)
You could in theory do queries on data stored in XML. (And maybe in practice soon.)
(correction) (Score:1)
"You could in theory do SQL queries on data stored in XML."
There are other "tree query" languages also.
Re:not even Turing Complete (Score:1)
In this case the graphics department skipped town and took the graphics software with them.
However, does it make sense to have a completely separate style sheet for just that element? (If even possible.) What about the other elements? If they change, then the custom one will not recogonize them.
(This reminds me of OOP's method granularity problem: how do you override 1/3 of a method?)
one minor nit (Score:1)
You also can have <TAG X="FOO"
Where there is no pairing, IIRC.
not even Turing Complete (Score:1)
Trade magazines often brag about how XML or style sheets "make format changes automatic" by having to only change a
single place in order to have color or formatting changes propagate automatically throughout an application or web-site.
Centralizing this information is a good idea, but the template approach (versus say a shared subroutine) has limits.
For example, I once was building a web-page where the color did not seem to match the colors chosen by the graphics
department. I verified that it matched using a screen "print" and some color tools. However, it was noticed that the color area
in question was next to a very dark area, and thus appeared lighter, even though technically it wasn't. I decided to add a
custom fudge that roughly resembled:
if pageID=5 and section=6 then
factor = 0.95
red = red * factor
green = green * factor
blue = blue * factor
end if
However, it was harder to extract and return the color values from the template settings than it would have been if they came
from "regular" code or SQL tables.
Just like COBOL, except.... (Score:1)
(re: "Now you can store your data with 1000% more words than before!")
SGML and Lisp language similarities (Score:1)
TBL said much the same thing [w3.org].
Well formed HTML (Score:1)
Has anyone else noticed their HTML is well-formed since they started using XML?
HTML is generally well-formed anyway, because unless you're deliberately using the XHTML doctype, then there's no reason for it to conform to XML well-formedness anyway. Non-XML well-formedness isn't bad, it's just SGML and not XML.
I switched to authoring XHTML about 18 months ago and have never regretted it. Sometimes it just keeps the code neat, sometimes it's enormously useful (when I want to either read it or write it with XML tools) and it's always consistent with the rest of what I'm authoring.
Swapping HTML to XHTML is full of pitfalls though. You can't just fix up the structural well-formedness, there's a load of character set and entity issues to fix too, especially if you use a range of character sets or encodings. Running it through Tidy will warn you on many of these, but it doesn't fix them for you automatically.
BTW - Does Slashdot still ignore <br /> ?
(If that was on one line, then yes it does)
Show me the SGML ! (Score:1)
At work, we've used DOM-like trees with SGML for years
You're lucky then, and you're definitely the exception.
I went shopping for SGML solutions in '97, and I couldn't afford them. Lots of nice suits, but there were no affordable toolkits and parsers to be had. - and don't mention DSSSL !
Now XML is everywhere. There's a deployed and working client-side XSLT engine on nearly every desktop (if not web browser) and the cost of building XML apps is peanuts.
If SGML was such a resounding and widespread success, then where is it all ?
Bad book - terrible RDF section (Score:1)
In a world of terrible computer books, and XML books being notably worse than usual, this one is at the lower end of the scale.
The RDF chapter misses the point completely, and given how stable (OK, moribund) the RDF spec was for a long time, it doesn't even have the usual excuses of a fast-changing field.
Don't buy any books on XML alone. They're all pretty uninspred. Go to xml101.com [xml101.com] or somewhere for a tutorial instead. Download the Microsoft XML SDK [microsoft.com] - even if you're using a non-MS dev platform, it's a damn good desktop DOM & XSLT reference (although you'll need a Windows box to read it).
The only book worth reading is Michael Kay's XSLT book [amazon.co.uk] from Wrox. You need to know XML pretty well beforehand, but it's a good XSLT tutorial and a decent reference.
Re:Old idea new format (Score:1)
ASN and XML (and that includes SGML) address different ends of the same problem, although they do overlap hugely.
ASN is a "wire protocol", and that's all it is. It takes some pretty low-level data typing concepts and describes a serialization for them. It's a very good serialization, and it's robust against a whole range of platform variables, but they just never lift their heads out of the trenches to look over the parapet.
SGML / XML are pretty low level too, but they're a whole level above ASN. Read the XML Infoset [w3.org] TR -- Can you imagine ASN describing that level of abstraction ? SGML (but not so much XML) let you deal with a bunch of structural issues by use of a DTD -- again, ASN would be left far behind.
VB Best Language Ever (Score:1)
a) an incredible polymath who never sleeps and writes like a demon
b)A hack writer who just re-gurgitates the documentation for people too lazy to read it
c) A pseudonym for a number of other writers
What do you all think?
Re:xml (Score:1)
Communications between servers which should share similar information is nice, I have used it to update databases that are pretty much static from one side of the firewall to the other. WDDX [wddx.org] is usefull for this and its a nice way to get things from one type of server to another (for instance an ASP based webserver to a ColdFusion based web server)
So as you can see, it has lots of real world uses.
Re:The virtual machines exist (Score:1)
With XML, all what the new device will have to support is the XML communication protocol and no more.
As you can see, it's best for me to do things the way I know is best for my device, not the way the server, *believes* it should be. In order for such a solution to work, communication must be based on data-exchange-protocol, not API/SDK/etc. -- i.e.: programming languages.
---------------
Sig
abbr.
XML: so simple (Score:1)
- Know HTML? Fine. Forget everything except <, > and
/. - There are no predefined tags
- Open a tag like this: <TAG>
- Close the tag like this: </TAG>
- Case matters
- Group properly -- <A><B>DATA</B></A>
What else do you need to know? Oh, to be useful, XML must be accompanied by DTDs or (better) XDRs. Find industry-standard ones -- if you roll your own, you either need fiat or luck.(beyond the initial processing instructions which you'll just copy from a template when you need it)
Now, the truly useful aspects of "XML" have little to do with XML itself. For example, you need to intelligently plan a XSLT for translation and presentation. The W3C DOM is a must for programming. XPATH! SAX... SAX2... oy vey....
Re:XML: so simple (Score:1)
Re:one minor nit (Score:1)
Re:xml (Score:1)
Umm, you could mark up data using XML making it self describing.
Re:xml (Score:1)
2) With the inclusion of DTD's, to enforce a common layout, you can check to see if an XML document will fit your data model and work with your exisitng applications.
3) Off the shelf parsers (e.g. SAX and DOM) will save you time generating and reading your data sets.
Re:Is this a good first book on XML? (Score:1)
I'm not a professional programmer or computer science student, so I found it helpful to read Just XML to 'get my head round things' before moving onto the more technical book.
Re:The more things change..... (Score:1)
Re:For how many year will XML be the Next Big Thin (Score:1)
Re:For how many year will XML be the Next Big Thin (Score:1)
At work, we've used DOM-like trees with SGML for years. They make a very nice and flexible data structure, with their logical organization. For us, XML has been seen more as a simplification of what we already do, rather than a revolution. As a result, perhaps some of the revolution is happening far below the surface of what people normally see.
Re:as with CSV (Score:1)
Now try adding a field/tag to an xml file. Older programs will ignore it, and new ones can use it.
XML is more flexible and forgiving.
xml (Score:1)
Re:One thing bothers me... (Score:1)
XML? SOAP? DOM? Bloat? (Score:1)
Re:One thing bothers me... (Score:1)
Oh, since about 1987 [ioccc.org].
XML is very useful... (Score:1)
- open up your data to other patforms, programming languages (not markup languages) and tiers in the enterprise.
- participate and adhere to a published and accepted DTD (Schema) for the XML data you are generating.
- choose the right underlying protocol. Unfortunately the prime candidate for the "ideal" protocol for tranporting XML content is causing market segmentation mainly due to the disparity of environments into which XML data is used. SOAP (XML over HTTP) is viable only for a low volume of messages or very high speed networks. XML over IIOP is more efficient but lacks standardization (what does your IDL interface look like). Then you've got other proprietary solutions like MQSeries and other budding standards like XML-RPC which are muddying the waters.
- Lastly, the cost of marshalling/unmarshalling XML documents using something like the DOM API is prohibitive. I know, I know, you can get your hands dirty by using SAX directly but it is extra work and usually ends up specific to a particular XML document DTD or Schema. JDOM is a decent enough API but is Java only.
I'm not knocking XML - it a young specification with massive industry support which will hopefully give rise to mature systems. Lets keep those vendors from hijacking either the XML or vertical industry data specifications though. Otherwise you may as well use byte streams - same vendor lock-in but more efficient.Wrox Press's "Professional XML" (Score:2)
Re:xml (Score:2)
It was a huge advantage, but not because XML is some amazing breakthrough, no, just because it's a standard meta-syntax. So we can re-use the XML parser on each data source rather than having to write a whole new parser for each data source, which is the way that sort of thing used to go.
So if MapQuest started offering a new data service that we subscribed to, like driving directions for flying cars, it would be very helpful if they offered the data served from their servers in XML -- just because we are already set up to use XML.
So the whole magic of XML is just that it's standard and flexible. That makes it highly worthwhile.
I have my doubts about other XML related subjects like XSL and XHTML, which may not ever get hugely popular. But XML itself is already hugely popular -- behind the scenes where you may never notice it, busily exchanging data with remote servers.
Re:xml (Score:2)
The main advantage of XML is that it gives you not a common document format (since DTDs differ) but a common syntax, so you can use a common parser. That's a win, but it's not the cure for all the world's problems.
Old idea new format (Score:2)
I don't know if it is just me, but does anyone else here deal with that "interesting" data represenation language "ASN.1" (Abstract Syntax Notation 1) with its associated binary representation BER (Basic Encoding Rules)?
ASN.1 defines a textual language for the representation of named primitive data types (strings, integers, real numbers, bitstrings, etc), structured ways of grouping them together (sequences, sets, etc).
BER provides a machine-independent way for these to be represented 'on-the-wire'. These representations are also abritrary-precision and have other cool features.
Fortunately or unfortunately (depending on your perspective and religion with respect to 'ISO/OSI' standards) ASN.1 never really caught on in the Internet world (SNMP and LDAP permitting).
However, I see it as playing a very similar role as XML. (Machine-independent representation of arbitrarily complex structured/nested data).
The main difference is that the BER represenation of ASN.1 is a (somewhat complex) binary format, whereas XML is text-based.
This is both an advantage and a disadvantage (more compact, harder for humans to read).
I'm wondering whether it is worth anyone's time writing up a BER XML translator to attack those 'but XML is too verbose' criticisms...
Now that is a profound observation! (Score:2)
Maybe I will write a Perl program to post that comment to Slashdot about every article that comes up. I'll call it "first_post.pl" It will do constant HTTP GET's of the webserver, and post that comment right away whenever there is a new article. I will be the first-post king!
XML not being the "do-all" (Score:2)
It really irks me when people say that about "X", each language has something that it does especially well, XML has its place...
we've been shipping for over a year (Score:2)
control language, parameter management, and
report generation. It's not the core technology
but useful. It is not necessarily the best
featured way of performing these functions,
but from a life-cycle maintenance point of view.
We need things likely to be around for ten years.
Re:Is this a good first book on XML? (Score:2)
Well, I'm currently reviewing O'Reilly's Learning XML, but I'd still say that Inside XML still seems to be a better book for beginners. Mainly because you can continue on with this book and increase your knowledge once it teaches you the basics, whereas advanced topics like XPointers and XLinks are pretty lacking in the O'Reilly book. O'Reilly's XML in a Nutshell is good, but if you choose Learning XML, it's pretty much a necessity (if you're into that fancy book learnin') because of Learning XML lack of advanced topics.
Another book that I'd recommend for beginners just below Inside XML is the second edition of Just XML. It's not as thorough as Inside XML, but it still manages to delve into quite a bit, like XLinks and XPointers (and covers them well for beginners, slowing down for parts that the author knows his readers will have trouble wrapping their heads around). The cool thing about it is the author's very approachable style, which makes for a very quick read (plus, there's a lot of anecdotal fluff that you can skip if you're not up for being amused), and the best part is that throughout the book, you're working toward building a B-movie database. The hands-on approach is nice, as I know a lot of XML newbies are left thinking, "But what can I use this stuff for?" Do make sure that you get the second edition. Again, I've just started Learning XML, but it's not seeming like it'll top either of these two. (Not that I think it's a poor book.)
Stay away from O'Reilly's XML Pocket Reference. It's too old. In the next month or two, they're coming out with a second edition of it, which I would expect to be a great pickup for the price. Wait 'til then.
Cheers,
Re:Did Vince McMahon just buy the XML? (Score:2)
Uh, scotch that. "flying buttrice" won't fly as a tag name, as one can clearly see from the spec. [w3.org] The BNF (buttrice-naming form) clearly states that whitespace separates a tag name from an (optional) list of attributes or the final ">". Nobody wants a malformed buttrice. ;-)
Portability. (Score:2)
Little XML data (Score:2)
Is there a repository of XML data? A list of links, maybe?
The virtual machines exist (Score:2)
Re:xml (Score:2)
Re:xml (Score:2)
XSLT book (Score:2)
Re:xml (Score:2)
Or don't, since arguably, you're the only person/company that'll ever use that data. Just send the data.
XML describes the syntax only, not the content. I would argue that the syntax is never the important part of the message. Hence regardless of whether the reader can figure out the syntax of the XML encoded data that describes itself (woo.) your reader would still have to be partial to information about what to do with it.
Since the bulk of your data is content, and the bulk of what must be done with it cannot be described through XML and syntax descriptions, then the bulk of your work will be writing your reader, and your writer. Whom does it aid in that case that the data is in the almost human unreadable XML format, as opposed to being either more readable or more compact as per your inevitable specifications?
-Daniel
don't believe the hype - zootv [U2]
Centralized ASN.1 vs. Decentralized XML Standards (Score:2)
Also analogous to SQL (Score:2)
Cool, but not trivial (Score:2)
any XML book that's any larger than a post-it note, to largely be filled with useless information on unrelated topics.
My "XML Book" is mainly double-sided prints of TR's from the W3C site in a ring-binder. It recently spilled over into a second 2" thick binder. I use all of this stuff on a regular basis - I also have most of it available as off-line webbage on my laptop.
Do you understand HTML tags
There's more to it than that. If you said SGML, then you might be closer to it.
Try this - Is a "naked ampersand" (i.e. not ) valid HTML ? Is it valid XML ? If anyone still reads Usenet, and the webmastering groups, then follow the recent thread in there on just this subject (where I had my butt spanked for getting it wrong). It's not as simple as you think, and it's not all the same as HTML.
What XML is "really" about (Score:2)
Lets face it. When Java was interdicted, its goal was to have Applet running in your home refrigerator, and toaster to name a few -- this was the basic goal of Java. With the arrival of the browsers, this goal was extended to computers so that you can write your program once and it will run on any computer (the "write once run everywhere" slogan.)
While the underlying principle of Java is very powerful, achieving it is so hard. The main reason is due to the fact that you will need a JVM, without which the idea of run "everywhere" is useless.
While for a full fledge PC this is not much of a problem (almost every flavor of an OS out there today has some version of JVM), this is a serious problem for new devices and as well as for companies that want to use Java. Here is why:
1) In order for Java to run on a new device, a JVM must exits for it.
2) In order for an existing application to run in a Java environment (using JVM) the application must be re-written in Java
Sure those issues can be addressed, but doing so you end up by making the new device and the new language "tightly coupled" to Java and JVM. In a client/server environment, this is a limited design such that it means the client part must be bounded to the server part.
XML frees you from this "tight coupling". All that I need to do is publish my Schema using XML and any application written in any language running on any device can now communicate with my application. So if my application provides a service to process patient record and I publish my API to my server-application via a Schema and XML-SOAP, than the client can get my service by simply adhering to my Schema -- the client can be written in any language and running on any device.
In short, XML is all about "data exchange protocol" -- the communication between two XML enabled applications is happening at the data-encoding-level. This is the power of XML where an API or SDK based solution can't solve.
So from now on, stop thinking about XML as "just a markup language" -- XML is a new way for which applications (and soon, components) well start communicating. The future of programming is based on data-communication not API or SDK or a language.
-- George
---------------
Sig
abbr.
Re:XML has limited use (Score:2)
I think you mean it is not a programming language.
XML = eXtensible Markup Language
It is a language. It has a defined [w3.org] syntax and semantics.
XML, GNOME, you'll just have to wait. (Score:2)
GNOME [gnome.org] wasn't built in a day.
Re:Learn XML. (Score:2)
http://www.google.com/search?sourceid=navclient&q= xml+tutorial [google.com]
Re:Old idea new format (Score:2)
--SM
Seriously, after dealing with some of the butt-ugly binary encoding schemes out there, ASN.1 looks pretty darn good.
As others have pointed out, however, ASN.1 and XML live in totally different domains. ASN.1 is not human-readable, and XML is useless for binary data.
--
XML is cool (Score:2)
XML Certification Test:
Question 1: Do you understand HTML tags?
Answer: Yes.
Result: You're certified.
Anyways, you'd have to expect any XML book that's any larger than a post-it note, to largely be filled with useless information on unrelated topics.
Re:Cool, but not trivial (Score:2)
The following are the only reasons I can think of about why somebody would have even one 2" binder on XML.
They are writing a parser and want it to adhere to the specs.
They are anal-retentive and absolutely have to know everything about everything or they feel they now nothing.
They feel they're more professional if they have large binders full of "specs" to make them seem more intelligent to clients/PHBs/co-workers.
They truly don't understand the simplicity of a given subject and make it more complex than it is.
Sadly, it's the last bunch that seems to have the most influence and usually end up bastardizing everything they touch into something it should have never been.
Let's get one thing straight. XML is nothing more than a fucking file format! If you need anything more than a basic structure of the format then you are stupid. If you need a book to tell you absolutely every way to use the format in every language, then you are also the laziest person on the planet. You want to parse an XML file in Perl, spend 3 minutes glancing over the XML::Parser mod. You want to do it for Windows, spend 10 minutes browsing the DOM reference on MSDN. Its so basic, don't try to turn it into something complex so you can impress others.
If you can't understand it, then you must be a VB programmer probably on your way to upper management. If you would spend the time looking up how "&" is treated and discussing it in newsgroups instead of just putting one in an XML file and parsing it, then you already ARE upper management. Don't forget to mark on your time card, just exactly how much time you spent on research of a single character.
Just what the world needed...
...something so simple, idiots can understand it well enough to make themselves look smarter to other idiots.
Re:Why write a book about it (Score:2)
But I do hope your little XFL thing lasts. I believe that at long last the US soul has been mirrored in sport: a pefect mix of agression, vanity, and reductive dualism that reflects everything that Americans hold dear.
We thieves, we liars, we vandals, and poets. Networked agents of Cthulhu Borealis.
Re:xml (Score:2)
What if you're transmitting results from a database query in plain text? With your example, you might say, "put all data for one row on one line." Then what happens if some of the data is multi-line? Well, you have to escape that data somehow.
With XML you can define a "row", and inside a row you can define a "column", and each value in your columns can have well-defined types.
So, by all means use
KEY1="value1"
KEY2="value2"
but if you want something more robust for passing data across standard implementations in many languages, use XML.
XML--logical next step up from UNIX text files (Score:2)
The problem with tabular data is that it doesn't let you represent a lot of information in a convenient form: people often do need and want hierarchical/tree-structured data. And tabular data in UNIX isn't self-describing. Configuration files, package descriptions, bibliographic citatinos, etc. all need fairly complex descriptions.
There are many ways of representing tree structured data. XML wouldn't be my favorite, but it is workable. And XML is getting a fairly complete set of tools for dealing with tree structured data: search, extraction, restructuring, etc.
With this, maybe the Linux community will pick up some of that old UNIX spirit again. Today, the habit seems to be that when anything needs to get done on Linux, someone writes a big Gnome or command line program in C, or, on a good day, writes a monolithic Perl program. For example, something like "rpmfind" should really just be a collection of a few command line tools: something like the Xerces tools for extracting information, gunzip to uncompress the data, and curl to retrieve information. The same is true for a lot of other Linux applications.
Oh, if you want to play around with XML, I found some of the Apache Xerces tools at http://xml.apache.org/ [apache.org] to be quite useful. They come in both Java and C++ flavors.
Re:xml (Score:3)
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.
Re:XML will set you free (Score:3)
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...________________________
When XML is useful (Score:3)
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.
Re:XML (Score:3)
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.
Other XML synergies: Re:XML is very useful... (Score:3)
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.
XML is just a descriptive markup (Score:3)
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>
XML will set you free (Score:3)
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
Re:XSLT book (Score:4)
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.
Did Vince McMahon just buy the XML? (Score:5)
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 [ridiculopathy.com]