Fog Creek Software
Discussion Board

XML Book suggestion please

As someone who has been in this industry for a couple of decades, and who dabbled with SGML and Lisp back before a geeky English scientist and a podgy U.S. college boy from the mid-west changed the world, I find it hard to get excited about XML and all the wacky related technologies. If anything XML seems to be a messy recapitulation of Lisp S-expressions with extremely bad attitude (and a pointless distinction between attributes and elements).

Many of these technologies seem plain absurd to me, I could go on for ages but I will single out XSLT. It seems to me a 'category error' - there is no more need for a programming language that manipulates XML to be in XML, than for a programming language that manipulates poetry to rhyme.

Anyway. Obviously having started my fifth decade it is important to either grit ones teeth and learn to love the latest trailer full of reinvention of things that didn't work or were useless last time round the block, or stand in front of the mirror practicing 'would you like fries with that, sir?'.

Therefore can anyone suggest a book on these technologies that will appeal to someone who had been round the block a few times and is more than somewhat skeptical of them?

Ned Ludd
Monday, July 12, 2004


You might find this interesting:

Ged Byrne
Monday, July 12, 2004

> You might find this interesting:

Be still my beating heart! Yes, I will definitely have a look at that, thanks.

Ned Ludd
Monday, July 12, 2004

As someone who has also been around this business for (nearly) the last two decades I concur with your thoughts on XML and especially XSL. XSL is a horrible abomination. Could there be a more ridiculous notion than to write a programming language in XML format? Where it doesn't actually even make logical sense in certain situations (sorting for example).
yuk yuk yuk

Monday, July 12, 2004

I learned from and still love Elliot Rusty Harold's "XML Bible".

I have the 2001 edition and it's a bit dated, but I'm not sure if there's a later edition.

Monday, July 12, 2004

Well, a lot of the (not too broad information) I have about XML came from online resource. is a good start, and so is Norman Walsh' site. Books I liked about the subject are:

Perl & XML from O'Reilly and Associates (assuming you know Perl well-enough)

SVG: The Graphical Web by Kurt Cagle, which is a very nice book just on SVG.

My opinion on XML is that it is a nice technology and all. I'm not entirely happy with all other technologies, and naturally it is somewhat over-hyped. But otherwise it has its uses.

As for the comparison to SGML and S-expressions. Well, XML was intended as a more simplified and easy to process version of SGML, and I find that it achieved these objectives. As for S-expressions, XML is more expressive than them, and is somewhat less ambigious.

Shlomi Fish
Monday, July 12, 2004

I'm going to state that there are 4 paradigms in programming:

Procedural, which includes the languages we all know and hate/love/don'tcare like fortran, c/c++, apl, vb and lisp.

Set based, of which SQL is the predominant representative. I am leaning on placing Prolog and other AI/Searching languages in this bucket (you may think they go elsewhere).

Pattern based, of which regular expressions are the predominant sample.

Tree based, of which XSLT appears to be the only representative at this time. There may be some graph theoretic languages written up as academic papers.

I think that XML is a current fashion, much like AI becomes fashionable from decade to decade. As a (sometimes) crotchety old fart, I tend to look on the latest fad and try to decide how much effort should be devoted to learning it before it ends up tossed on the dustheap of history. It is possible that folks 10 years from now will wonder why we were using XML, as they will have some new fad.

You may categorize languages differently. But I see some folks are unable to think in set terms, so those folks have inordinate difficulties with SQL. Just like I have inordinate difficulty with regular expressions. It is possible that you can't see tree type thingies, so xslt might be hard for you, or xslt might just be a fad and its really irrelevant, which may be a better reason why its hard to figure out.

Books I use:
Java and XML (oreilly)
XSLT: Programmers Reference (wrox)
Java and xslt (oreilly)

book with almost no code, but makes clear why xml and xslt will help:
Content Management Bible

book I just picked up:
XML, XSLT, Java, and JSP: A Case Study in Developing a Web Application (remaindered, so it was cheap)

New Riders tends to have some books with a cd and bunch of code for playing with. JWiley tends to be good for theory or other issues. Sometimes oreilly and wrox are good, sometimes spotty (the more the pictures on the cover, the less focused). Charles River tends to focus on games, but I think that is the future of software (not the games as such, but the discipline in developing commercial software as well as it is the first place that academic research hits the pavement). You may prefer other publishers/editor teams. I also tend to mosey down to my nearest book store, grab a honking great armload of books and sit down in the cafe with some coffee and divvy the books into 4 piles: unchecked, not sure (check again after another coffee), buy this pile, and don't buy these. It can take me an afternoon to sort out where to invest/waste $100 to 200.

I use XML with .net at the office, but I'm learning java at home, hence the dual nature of the books.

Disclaimers/Weasel words: I know that there are some academic languages that can be placed in these categories, or may blur some borders, but I try to keep this categorization useful. Adding too many disclaimers and exceptions will make it useless for anyone other than a language bigot/lawyer. Your mileage may vary. Offer not available in all universes. Batteries not included. Blah blah blah, I know I talk too much, so what else is new?

Monday, July 12, 2004

I like Philp Wadler's site:

Grumpy old fart
Monday, July 12, 2004

> I like Philp Wadler's site:

Spooky, he was one of the people who taught me at university (not Edinburgh, though)

Ned Ludd
Tuesday, July 13, 2004

> Tree based, of which XSLT appears to be the only
> representative at this time.

maybe I am missing something but couldn't any language which allows some sort of closure / continuation / passing a block of code in as a parameter (of which there are many these days), perform this sort of 'tree based' processing?

Is it not really just a generalisation of the awk paradigm - with awk you have 'lump of code executed at beginning', 'lumps of code executed when the pattern is matched for each line', 'lump of code executed at end'?

Ned Ludd
Tuesday, July 13, 2004

*  Recent Topics

*  Fog Creek Home