Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Effective XML 269

Posted by timothy from the under-weaknesses-you-put-xml dept.
James Edward Gray II writes "I'm not an XML junkie and I thought this was a very good book, so I'm betting that XML aficionados will love it. Effective XML covers 50 best practices that all developers should know and use. This amounts to a book of distilled wisdom that will push you a good distance up the chart of XML mastery." Read on for the rest of Gray's review.
Effective XML
author Elliotte Rusty Harold
pages 304
publisher Addison-Wesley
rating 8
reviewer James Edward Gray II
ISBN 0321150406
summary A guide to the correct use of XML.

Before I tell you what's inside though, let me tell you what you won't find in these pages. Primarily you need to know that this book does not teach XML. I know a lot of books say that, yet still include an introduction or appendix that covers the basics, but this isn't one of them. You're expected to know XML from page one. Even syntax is only covered from a proper usage angle. Personally, I appreciated this. It always bothers me when an obvious non-beginner's book starts off by wasting a chapter on things I should already know. You just need to be aware when you buy that you won't learn XML here. Knowledge of namespaces, DTDs, the W3C's Schema Language, XSLT, and more aren't strictly required to get something out of this book, but they certainly would help you get a lot more out of it.

What you will get here is coverage of fifty miscellaneous topics spread across four sections on "Syntax", "Structure", "Semantics", and "Implementation". In "Syntax", ten topics delve into the details of things like DTDs, entity references and the XML declaration itself. It may sound silly to dig deep into a single line of XML that simply declares the format, but I doubt you will think so after reading that topic. There's a lot going on in that line and you want to be in control of those decisions instead of just copying and pasting. Entity references are an even smaller chunk of XML output, but they too get illuminated by a rare insight on how and when they should be used, and for what. Did you know that it is possible to write a namespace savvy DTD? I do now and I learned that in this section as well.

The second section of the book covers "Structure", and to me it was the best part. This collection of seventeen topics is loaded with good advice about how to build an XML document that will be ideal for anyone who needs to work with it. Here you see how metadata should be stored in XML, get tips on embedding binary content, learn which schema language is better for which tasks, and finally understand rare XML constructs like processing instructions and exactly what they are for. Additionally, there's a lot of general advice on the right way to mark up content that's really worth its weight in gold. Just one example of what I learned here is that I under appreciate mixed content for great constructs like <name><given>John</given> <family>Doe</family>, <title>Ph.D.</title></name>. If you like that, you'll enjoy this whole section.

Section three, "Semantics", deals primarily with parsers and their APIs. Again, you won't learn any APIs here. What's covered is their strengths and weaknesses and why you should choose a given API for a given task. SAX and DOM are the main focus of these ten topics, but there are other details sprinkled in, like XPath.

The fourth and final section is all about "Implementation". The thirteen topics here address client-side XML styling, server-side transformations, signatures, encryption, compression, and more. My favorite topic here was a terrific coverage of Unicode and how it affects XML. All developers should know at least as much about Unicode as what's printed here and this is a fine source to learn it from.

One thing that really stands out in the whole text is that the author isn't afraid to cover the dark side of XML. He will tell you where the design process was less than perfect, which tools have little practical value, and some of the problems with where XML technologies are headed. This isn't complaining though. All of this is targeted at how it affects XML developers today. You learn what you can safely skip and what should be outright avoided. The author even tells you what XML is bad at and gives you advice about when you shouldn't use it. That's the mark of a man who knows his subject, if you ask me.

All told, I think the author failed to completely convince me his way is perfect on only 2 topics. That means I learned 48 expert XML tricks. Surely that's worth the cost of the book in time and money. This isn't the first XML book you need, but I think it is the second XML book everyone should read.

You can purchase Effective 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.
This discussion has been archived. No new comments can be posted.

Effective XML More

Effective XML

Comments Filter:

  • Binding (Score:3, Funny)

    by 2.7182 ( 819680 ) on Monday February 28, 2005 @04:34PM (#11806854)
    I love the book, but once it encountered a humid day the binding fell apart. Anyone else have this experiance ?

  • hmmm (Score:2, Interesting)

    by elid ( 672471 )
    All told, I think the author failed to completely convince me his way is perfect on only 2 topics.

    Any ideas what those 2 are?

    • All told, I think the author failed to completely convince me his way is perfect on only 2 topics.

      Any ideas what those 2 are?

      1. XML is a good idea.

      2. XML is an efficient format for wire protocols, internal program messages, and databases.

      Actually I'm just kidding; there are definitely places where it has a purpose. Although I will probably never get why a closing tag requires a repeat of the file opening tag name...

      • Re:hmmm (Score:2, Informative)

        by computational super ( 740265 )
        Although I will probably never get why a closing tag requires a repeat of the file opening tag name

        Not sure if you were serious here or not, but this is necessary to disambiguate the following improperly formed XML:

        <start> Now is the time for all good men to come to the aid of their <noun>country</noun></phrase>

        which is either missing a "phrase" start tag or mixed up the start & end tags... in a long XML document, the parser can give you a better hint where to look for the e

      • Re:hmmm (Score:5, Insightful)

        by elharo ( 2815 ) <elharoNO@SPAMmetalab.unc.edu> on Monday February 28, 2005 @06:18PM (#11807854) Homepage
        Ever try to debug deeply nested LISP in a plain vanilla text editor? Ever try to find exactly which closing parenthesis is missing where? That's why end-tags have names. It's pure human factors. Computers don't care about this. People do.

        SGML (XML's precursor) did have minimized end-tags like . Experience proved this caused more pain than it alleviated. Hence the lack of minimized end-tags in XML.

  • The Problem With XML (Score:5, Interesting)

    by osewa77 ( 603622 ) <naijasms@NOSpaM.gmail.com> on Monday February 28, 2005 @04:40PM (#11806930) Homepage
    Is that it's not a very machine-friendly language (more wordy than it ought to be; parsing of tags is not very efficient) and it's not a very human-friendly language (the human style is free-style, really). I don't think it's a very good universal data description language. sorry that I had to go on a bit of a tangent...
    • What is inefficient about machine-parsing of XML (not a troll, I'm really curious)? It seems to me to be a logical structure for information.
      • What is inefficient about machine-parsing of XML

        Well among other problems, you typically have to parse & load the whole document in order to extract even a single piece of information. A DOM parser operates thus. A SAX parser may let you read from the top to where your data is.

        Contrast this with a binary format where you could navigate directly to your data and read a value. Imagine if you had to parse your whole database file in order to run a select statement.

        • Re:The Problem With XML (Score:3, Interesting)

          by sapgau ( 413511 )
          Yes, that's implementation.

          But the question was if it is a universal data description language. Sending binary will kill your data the first time you try to comunicate to a macitosh or Unix system (big endian, little endian).

          The common lowest denominator is just text, so to describe any structure we have trees in XML.

          Probably the confusion is the influence of Object Oriented design with Entity Relationship schemas in databases. The way that one-many relationships are described in both areas makes sparks

      • Re:The Problem With XML (Score:3, Informative)

        by redhog ( 15207 )
        Because you need to _parse_ it in any way at all. Simply holerith/runlength-encoding the data would be much better.

        Take XPath as an example. How do you extract the fragment pointed to by the expression

        foo/bar/fie[@naja='hehe']

        ? You read the document, counting opening and closing tags, until you read in a foo-tag at topp-level then you continue, counting as before, until you, before a foo-ending tag at topp level, reaches a bar-tag at second level, and then until you reach a fie-tag with the attribute naj

    • To be specific having spent the last 3 years working on XML I can suggest that there are numerous problems with XML.

      XML Tagging is tedious and stupidly top heavy in overhead. Contrary to being human friendly it isn't. XML Tagging should be shortened to a simple set of defined tag names and then type definitions. After that each name would be addressed by an index. Typing of data should be contained in a process to extract that is associated with either the tagging index or an over the top wrapper which

      • Re:The Problem With XML (Score:5, Insightful)

        by eap ( 91469 ) on Monday February 28, 2005 @05:50PM (#11807598) Journal
        Of course someone else might find a good way to tell me why I should use 40 characters to transmit what should have taken 10 characters and how it should have been faster or more efficient some way to use it. The whole concept was definitely good for a lot of programmer payroll time.

        I would not be so quick to dismiss XML because of traditional arguments. Having worked with several different ways of storing and transmitting structured information, I can say without question XML comes out easiest in the end.

        If you're only transmitting 10 characters, then yes XML is not for you. However, if you're describing dynamically changing, complex data, even in large amounts, XML is very handy.

        There are turnkey parsers for XML that are well tested and which allow the client to see an abstracted view of the data as an object, at any level of detail desired.

        Platform independence is built in.

        It's easy to syntactically validate XML, as it's done automatically. It's also easy to isolate logical validation into discrete units since XML couples easily to object oriented designs.

        Very large XML messages can be processed quickly using a pull parser. Pull parsing is faster than SAX and has the intuitive benefit of being client driven, not event driven.

        • And all that wonderful magic can't be accomplished with something like ANTLR, because...?

      • In my experience the main reason our clients want their data in XML is that most of them are afraid of single-vendor lock-in to proprietary formats, especially to smaller vendors they perceive could more easily go under - in other words, they want data longevity and a format they can easily process their data if they need to. And this trumps the inefficiency. Especially as people mostly transfer such documents across high-speed LANs and store them on modern 120+ GB hard disks and open them on machines with

        • There are also generic XML content editors which, although rather pricy, help reduce a lot of the negatives associated with working with XML (i.e. you would be crazy these days to be writing XML in e.g. Notepad).
          ... or poor
      • Two words: Web Services.

        It doesn't have to be SOAP. But if you are going to publish a web service you need at least to describe what the data looks like. And the client is not going to install your software to establish communication, he/she will only make a call to your server like a http request and you will respond with a stream of data.

        That data would be VERY useful if it is described in a standard format like XML.

    • Re:The Problem With XML (Score:5, Funny)

      by Procyon101 ( 61366 ) on Monday February 28, 2005 @05:36PM (#11807489) Journal
      I think that I shall never smell
      A standard worse than XML.
      A standard I am loath to use
      Though offered parsers to abuse;
      The designers couldn't pass a class,
      CS201 can kiss their ass;
      A structure no one can traverse
      pre and post order routes are cursed;
      What are it's types you cannot tell;
      Though it promised self referential.
      Standards are assigned by committee,
      But any fool can make a tree.
    • Even with the "descriptors", you still have to know how the data is laid out. It adds a ton of overhead, with, as far as I have been able to tell, little benefit. Hence, everything I program is still in good ol' comma (or some other character) delimited, without all of the XML fluff.

    • I don't think it's a very good universal data description language.

      You don't think it's a very good universal data description language? Well, let me confirm your suspicions: XML absolutely and totally sucks as a universal data description language.

      The thing is, I don't understand for the life of me why people got the idea that XML should be used for data description to begin with -- it wasn't designed as such. XML was designed to be a document markup language, and that's precisely what it is. It's a g

      • I think it's been said previously. Communication protocols are not easy to implement and if on top of that you add your own data representation, it will basically lock everybody into a very unflexible solution (not Universal). The thing is that XML excels at transporting data between computer systems. I'm talking

        Windows ->Macintosh ->Unix ->VMS Mainframe ->"Rusianiski" ->Windows

        Instead of agreeing with the authors/creators of all these systems in defining how a number or a date or a floati

        • Instead of agreeing with the authors/creators of all these systems in defining how a number or a date or a floating point is going to be sent over the wire, they can all agree on XML.

          And just what of this does XML help to alleviate? How is it easier to agree on a common XML schema than to agree on a binary protocol or any other ASCII-based protocol? It's exactly the same thing.

          So if the rusian guys have this very exotic computer that saves data in a very special format, it can still share data with th

  • One thing that really stands out in the whole text is that the author isn't afraid to cover the dark side of XML.

    [Obligatory Star Wars joke]

    • Re:Join the Dark Side (Score:5, Funny)

      by TripMaster Monkey ( 862126 ) on Monday February 28, 2005 @04:46PM (#11806991)
      XML: You killled my father!

      HTML: No, XML....I am your father!

      XML: That's impossible!

      HTML: Grep your code...you know it to be true.

      XML: NOOOOOOOOOOOOOOOOOO!
      • I know that this was an attempt at being funny, but I'm curious, did you say this because the author mentioned "darkside" in his review, or because html came before xml, or a combination of both?
        The reason why I ask, is because I thought "XML" is older than HTML, and is a simpler version of SGML (?), which HTML is also derived from ... no?

        • Re:Join the Dark Side (Score:2, Informative)

          by johndiii ( 229824 ) *
          HTML [wikipedia.org] significantly predates XML [wikipedia.org]. Though both are derived from SGML [wikipedia.org], they are in somewhat different categories (HTML being an application of SGML, while XML is a profile). HTML is a closed development path, however; future versions will be XHTML [wikipedia.org], which is a derivative (application) of XML.

  • damn (Score:5, Funny)

    by pyrrho ( 167252 ) on Monday February 28, 2005 @04:46PM (#11806997) Journal
    I want to say something funny about XML, but there is nothing.

  • n00b - help! (Score:5, Interesting)

    by dsginter ( 104154 ) on Monday February 28, 2005 @04:47PM (#11807000)
    After seeing what can be done with simple javascript and XML [apple.com], I'm wanting to get into this. Can someone point me to the best OSS way to do this (I can hear the groans now). I like Postgres but I don't see much in the way of getting it to spit out XML. I like documentation... MySQL? Am I missing something?

    • Re:n00b - help! (Score:5, Insightful)

      by aldoman ( 670791 ) on Monday February 28, 2005 @05:02PM (#11807175) Homepage
      XML is totally overhyped, which sadly makes people think it is a lot more complex than it is.

      Think of it more like CSV than mySQL. It's just a format for representing structured data. It also happens to be that it's quite easily read by humans.

      Yes, you can do incredibly advanced things with XML, but there is nothing you can do in XML compared to your own propietary data storing language.

      The reason people use XML instead of writing their own data storing format is simple:- there is a lot of tools for parsing it, which you'd have to write yourself if you had your own format.

      As for the javascript and XML example, it's impressive, but it's far more javascript than XML.

      • Re:n00b - help! (Score:5, Insightful)

        by Piquan ( 49943 ) on Monday February 28, 2005 @05:46PM (#11807569)
        The coolness of XML is not in the format (which sucks); it's in the technologies around it.

        RelaxNG, for instance, lets you verify that your XML file is built correctly for your app: you write a RelaxNG spec for your XML file format, and then it verifies that all the mandatory fields are there, in whatever order is necessary, with the correct datatypes, etc, etc. RelaxNG processors are part of most major XML libraries now, so if you're writing Perl you can just tell your Perl library to validate your file and it's done. If you're editing in Emacs (with nxml-mode), you can point Emacs at your RelaxNG file, and have tab completion, error highlighting, etc, etc-- all customized for your file format.

        XSLT lets you take an XML file and perform transformations on it into another (possibly XML) file format. Need to convert XML into SQL INSERTS? Piece of cake. I use it to extract particular parts of an XML file and convert them into a significantly differently-ordered Lisp structure.

        Most modern web browsers are becoming CSS engines rather than HTML engines. So you can stick a CSS stylesheet reference at the top of your XML file, and have the CSS generate something that looks like what you want the user to see. The data file looks good to the app, and looks good to the user. You can also (with some browsers) use more powerful transformations using something like DSSSL or XSLT.

        DOM for a standard data manipulation API, so each program you write doesn't have a different data access language. XPath as a language to perform more complex queries. XML Namespaces to let users or apps tag their data with extensions. XInclude for data sharing. All of these are things you get for free with XML.

        All of these are general technologies, not specific apps. So they should be usable in most major libraries in most languages. (If you're using Perl, I'd recommend XML::LibXML.)

        Don't think of XML as just a file format, because that part sucks. Think of it as a buffet table of technologies. When you write a program, 10% is to do the program's processing; the other 90% is to handle I/O, data management, and other housekeeping. Using XML lets you get a lot of that for free.

        PS: I'm not an XML fanatic. A year ago, I was told to use XML for one particular project and was disgusted at the idea. I still think that XML gets a lot wrong, but I've come to recognize what benefits XML provides.

        • What's your beef with the file format? And what's your proposal or suggestion for an improvement?
        • XSLT lets you take an XML file and perform transformations on it into another (possibly XML) file format. Need to convert XML into SQL INSERTS? Piece of cake. I use it to extract particular parts of an XML file and convert them into a significantly differently-ordered Lisp structure.

          I really like XSLT for code generators, with the meta-data in XML. I do, however, miss the sheer perversity of using Access VBA to generate Java.
      • let me see if I can reduce this to a human-readable folk saying:

        If the only tool you have is a machine gun, everything starts to look like enemy soldiers.
    • Why don't you have your xml file really be PHP that exports XML.. Then you can do something like:

      <?
      // skip mysql init stuff:

      $dom = new DomDocument();
      $root = $dom->createElement("root");
      $dom->appendChild($r oot);

      $items = $dom->createElement("items");
      $root->appendChild( $root);

      $sql = "select * from items order by Id asc";
      $qu = mysql_query($sql);

      while ($s = mysql_fetch_array($qu, MYSQL_ASSOC))
      {
      $item = $dom->createElement("item");
      $items->appendChild($item);

      foreach ($s as $k =

    • Look here [rpbourret.com]. Several of the products that he mentions are addons for PostgreSQL.

  • Dear XML-Junkies, (Score:5, Funny)

    by Letter ( 634816 ) on Monday February 28, 2005 @04:52PM (#11807056)
    <letter>
    <salutation>Dear XML-Junkies</salutation>
    <body>
    I type all my business letters in <link href="http://www.google.com/?q=XML>XML</link>. Sometimes it can be a bit <link href="http://dictionary.reference.com/search?q=ver bose">verbose</link>.
    </body>
    <signature>
    <name ><nickname>Letter</nickname></name>
    </signature>
    </letter>
    • nsgmls:letter.xml:1:0:E: no document type declaration; will parse without validation
      nsgmls:letter.xml:4:78:W: character "" is the first character of a delimiter but occurred as data
      nsgmls:letter.xml:4:78: open elements: letter body
      nsgmls:letter.xml:4:114:W: character "" is the first character of a delimiter but occurred as data
      nsgmls:letter.xml:4:114: open elements: letter body
      nsgmls:letter.xml:4:132:E: net-enabling start-tag not immediately followed by null end-tag
      nsgmls:letter.xml:4:132: open elements: le

  • XML Seems Cool (Score:3, Insightful)

    by Aknaton ( 528294 ) on Monday February 28, 2005 @04:56PM (#11807095)
    XML seems cool to me. I like the thought of being able to design a schema to suit my personal needs. But when it comes time to make use of that schema and actually keep data in it, it seems to be useless, as least as far as an end user (non programmer) is concerned.

    Do I have the wrong impression?

    • Re:XML Seems Cool (Score:2, Insightful)

      by gizmofan ( 862506 )
      XML is a way of decorating data with meaning but it's not the most efficient or effective way of doing it. From a software point of view it's expensive to parse - incredibly so when heavily nested/structured and just in terms of size it can be huge in terms of the raw data that it's actually transmitting. The main problem I have with the way XML is often used is the fact that's it's the worst of both worlds. It documents the data that it encapsulates badly from a human point of view (it's difficult to read
      • Why not? Because those two documents (lisp s expressions and documentation thereof) are only in synch once, at creation. From there forward, never again.

        Everyone here at /. whines about the readability of XML. I have yet to see an example of an improvement.

        As for performance, for 99% of your applications, it just doesn't matter. Software analysis and development time is much more expensive than clock cycles.

        Would I use XML for a database? Probably not without a lot of convincing. Do I use it for da

    • Re:XML Seems Cool (Score:2, Informative)

      by elharo ( 2815 )
      Please don't tar XML with the schema brush. One of the unique innovations of XML is that schemas are optional, and need not be agreed on. Schemas can be useful as I discuss in Item 37. However, they are misused and overused far more often than they're used correctly.

      Really, schemas are just convenient tools for a few special purposes. Not everyone needs them, and no one needs them all the time. Schemaless XML is a lot more interesting and practical.
  • I just bought a book a couple days ago. Great one so far, even it does not teach you XML, but for anyone who have even small experience with XML, the book is still great. Just like me, you will pick up really fast.

  • FYI (Score:5, Informative)

    by Anonymous Coward on Monday February 28, 2005 @05:09PM (#11807245)
    Bookpool has it for $28.50 [bookpool.com]. Don't click the bn sponsored link (where it's a whopping $44.95).

    PS, I don't work for Bookpool, I hate it when /. gets a kickback from doing something dumb like clicking the link to overpriced merchandise.

  • Try the other "Effective" books, too (Score:5, Informative)

    by Eric Giguere ( 42863 ) on Monday February 28, 2005 @05:12PM (#11807274) Homepage Journal

    If you like this book, don't forget to check out Scott Meyers' Effective C++ or Joshua Bloch's Effective Java. Both are great. I devoured Meyers' book when it first came out, and I was happy to see Bloch's book was similarly useful. There is also an Effective Perl book out, but I don't know how good it is -- it follows the same general format, but hasn't been updated since 1997. (Neither has the C++ book, but C++ hasn't changed that much since then.)

    Eric
    See your HTTP headers here [ericgiguere.com]

  • Just because you CAN... (Score:5, Insightful)

    by IGnatius T Foobar ( 4328 ) on Monday February 28, 2005 @05:27PM (#11807391) Homepage Journal
    Sometimes, the most effective use of XML is to simply not use XML at all. XML is a wonderfully useful tool when applied correctly. It's architecture-independent and is a great way to communicate unstructured and/or hierarchial data.

    Sometimes, though, your data can be simple enough that XML is overkill. Software developers need to make themselves aware of situations when they might be better served by a simple "flat file" of delimited data. In situations like this, using XML can amount to what I like to call "gratuitous complexity."

    Always use the right tool for the job.
    • Sometimes, though, your data can be simple enough that XML is overkill

      True enough, however, simple data all too often becomes complex data. That's why it's a good thing to be "extensible".

    • These days data has to be pretty damn simple to justify using a flat file rather than XML. I wrote more about this in my previous book, Processing XML with Java [cafeconleche.org] than in this one, though. Chapters 1-4 discuss this in some detail.

      Real-world data often gets messy in ways that don't lend themselves to flat files. For instance, two of the thorniest problems:

      1. How do you handle encoding detection and international characters?
      2. What do you do when the data contains characters you're using as field delimiters?
      • 2. What do you do when the data contains characters you're using as field delimiters?

        Both of these are completely solved by XML with no extra effort on your part, and these are hardly the only issues.

        CDATA is delimited at the end by ]]>. There is no way to escape this delimiter. If you need to enclose one XML fragment in another using CDATA, you had best base64 encode it, because there simply isn't any way to nest them.

        This is not what I call "well thought out"

  • overstock (Score:2, Informative)

    by Quiet_Desperation ( 858215 )
    $28.27 at overstock.com.

  • A perfect eXaMpLe of a good use for XML (Score:5, Funny)

    by swrider ( 854292 ) on Monday February 28, 2005 @06:02PM (#11807700) Homepage
    There are valid uses for XML. Just look at http://www.x-cp.org/ [x-cp.org]
  • I've seen XML used for quite a while in a number of completely inappropriate situations such as configuration data, RPC implementations, scripting etc.

    Yet, every time I see XML (mis)applied in those cases I keep asking the fundamental question. What does it allow me to do that a decent Lexer and Parser does not? You could be sending grammar files just as easily and without the ridiculous verbosity of XML. Most parsers can work with either text or binary and BNF has been a golden standard for decades. XML

    • Hmm, that's one I haven't been asked before.

      I suspect what it offers is that you don't have to define and write your own BNF grammar, and then implement it in lex and yacc or similar tools.

      Grammar design is non-trivial, especially if you need to consider issues like internationalization. Picking XML as the underlying format means you don't have to do this work yourself. Why reinvent the wheel?

      Sometimes you do need something different, but a lot of alternative formats don't really have a good reason to ex
      • I agree with the i18n bit, but it's only handled in XML better by the virtue of XML being newer than most parser generating tools out there.

        As far as XML development being "easier"... I find that questionable (but it may be my personal view). If the problem domain is trivial then it might be the case that your XML schema happens to be simpler than your BNF grammar. In most non-trivial cases I find it's about even. As far as verbosity goes, 99% of the time your custom grammar will be a lot more space effic

    • I've seen XML used for quite a while in a number of completely inappropriate situations such as configuration data

      Let me start this off by saying that I'm no fanboy of XML. If anything, I'm the local "get XML away from me" person.

      But config files are one place that I actually like XML. And I like it because these files are (1) typically fairly small and (2) I don't want to have to write and debug another lexer/parser. I have a utility (castor) that handles the parser for me based on the objects I han
      • OK. I wasn't specific enough. When I'm talking about config files I'm mostly thinking "Java config files" or even more specifically "J2EE config files". I find that way too much stuff ends up in XML config files that should actually be implemented in the Java code itself. In some cases, perhaps scripted with Groovy or Beanshell. XML is not the vehicle for application scripting alas that's what most j2ee "config" files have become.

        Antlr (actually that's my personal favourite) is harder to learn than JDOM b

  • Delicious irony (Score:4, Funny)

    by dubbayu_d_40 ( 622643 ) on Monday February 28, 2005 @06:37PM (#11808034)
    ridiculing the verbosity of xml, on a web page.

  • so do we love or hate Mozilla and FireFox today? (Score:5, Insightful)

    by roman_mir ( 125474 ) on Monday February 28, 2005 @06:51PM (#11808148) Homepage Journal
    After all XUL and RDF together with js, css and resource files - that's what makes FireFox tick.

  • This book appeart to be for people who already know XML, but need to work on their technique. (I refuse to use that vague term "advanced users".) If you're an XML newbie, you probably need to buy The XML Bible [ibiblio.org] from the same author, Yeah, the title is dumb (computer book publishers have a thing for dumb titles) and the CD is screwed up. But I know of no other book that will allow your typical HTML hacker to make the transition to XML so easily.

  • What's so bad about XML? (Score:4, Insightful)

    by rikkus-x ( 526844 ) <rik@rikkus.info> on Monday February 28, 2005 @07:16PM (#11808381) Homepage
    I give customers a specification showing how I would like data sent to me. They can use the specification to tell them how to store their data, because they can read it. They can check that their data matches the specification, because their machine can read it.

    When I receive their data, I can check that it matches the specification, because my machine can read it. If there is something wrong with their data, I can point out where it's broken, because it's human-readable.

    Writing specifications is easy. Writing generators and parsers is easy. The tools are ubiquitous. Generation and parsing are usually fast 'enough'. The standards are freely available. Complex data structures may be described. Data may be transformed using a common language based on XML itself.

    Yes, I'd like it to be easier to write XML parsing tools. Yes, I'd like it to be easier to write tools which handle XML more efficiently. No, the two points above don't make XML the devil's data encapsulation.

    Rik
    • Nothing,

      People just fail to realise what XML is (or isn't). Basically XML is just a way for you to define your own (markup) language for any purpose.

      That it. Is not a database replacement. It won't walk on water or feed the hungry or kill all the communists/terrorists.

      But if you want to persist textual data with structure, in a form that will most probably be readable in 20 years time, XML is for you.

  • I realize that he was defining the vocabulary of the subjects that he will talk about later. I recognize this as very important first step that many authors take for granted.

    Vocabulary increases our understanding of the entities that we want to work with, so we don't spend our time arguing about what we are trying to say...

    For this I remember Ludwig Wittgenstein and his methodology of achieving the Truth by establishing the meaning of words and their relationship with thoughts and their link to reality. I
  • When it comes to speed, XML sucks. It does provide incomparable interchange of data on a human- and machine-readable level. It would be nice on the other hand to be able to select a faster standard when both ends of a transaction support it. XML would become the lowest denominator.

  • Importance vastly overstated (Score:3, Informative)

    by s88 ( 255181 ) on Monday February 28, 2005 @10:25PM (#11809510) Homepage
    The review almost sold me on the fact that I could actually learn something from this book. Looking at the sample chapters here [cafeconleche.org] told me the truth

Slashdot Top Deals

Real programmers don't comment their code. It was hard to write, it should be hard to understand.

Close