Related link: http://www.xsltblog.com/archives/2004/11/python_and_xmlx.html#more
I came across one of those blogs today where an author who sort of half-understands a subject decides to test that knowledge by tearing into the work of another author. This time the tearee was me (with respect to my most recent O’Reilly column “XML.com: Location, Location, Location” and the attack happened to be laughably off-base). I tried to submit the rebuttal as a comment to the blog posting itself, but the server gave me a script error, so here it is.
Dear <XSLT:Blogger />, your comments on my article are extremely unfair in that you select quotes from the article entirely out of context in order to make an entirely bogus point. If you look at my published body of XSLT out there (and there is a lot of it), you won’t find a single place where I use a construction such as /labels[1] to access the document element of a well-formed source document in XSLT.
In the article I was demonstrating techniques for automatically generating XPath, not examples of elegant, hand-written XPath. I certainly mention a couple of times in the article that the XPaths aren’t ideally constructed. And why should they be? They’re examples of machine generation. How often do you see machine generated code that is very elegantly constructed. Have you seen XSLT generated from schematron.xsl? Now top this off with the fact that the article (already pretty long) was intended to be a demonstration of overall techniques, not a comprehensive micro-analysis of every facte of XPath generation.
As you admit, all the generated XPaths are technically correct. As for stylistic issues, of course I know that there is only one element node in a well-formed XML file, and that XSLT requires normalization of text nodes are automatically normalized. I expect that most people who can follow XPath know that as well. The article was not a tutorial of XPath, nor did it claim to be.
And by the way, while you were climbing your high horse, you made a fundamental error of your own:
‘Second, there is no text node that is a child node of �emph�. The text contained within the �emph� element is the value of �emph�, not the value of a text node that is a child of �emph�.’
Are you telling me that you are not aware that
string(/labels[1]/label[1]/quote[1]/emph[1]/text()[1])
results in “Midwinter Spring”
or in terms you wouldn’t find “annoying” that string(/labels/label[1]/quote/emph/text())
is the same value as
string(/labels/label[1]/quote/emph).
Yes, indeed, I just re-read, and you are saying just that in an attempt to “correct” me. Sorry, but the spec contradicts you. I know, because I have implementd XPath and XSLT several times over and I know the spec very well.
In conclusion you were not able to point out a single actual error in my article, so perhaps you should not try to pull down the work of others by cutting their context to shreds in future. <XSLT:Blog /> is generaly a nice site. I’d be as happy as any other reader if you didn’t ruin it with more of the same.
Thanks.
Uche Ogbuji
Except in more complex cases:
string(/labels/label[1]/quote/emph/text())in this case is indeed the same value asstring(/labels/label[1]/quote/emph), but if thatemphtag happens to have mixed content, then it's not. Far from splitting hairs, it's a pretty fundamental distinction. Missing that kind of kind of doesn't give the stylistic complaints much ground to stand on…Except in more complex cases:
string(/labels/label[1]/quote/emph/text())in this case is indeed the same value asstring(/labels/label[1]/quote/emph), but if thatemphtag happens to have mixed content, then it's not. Far from splitting hairs, it's a pretty fundamental distinction.Except in more complex cases:
You read the code listing in question, right? The emph tag does not have mixed content. So you have the sliver of a point. I didn't state the equivalence in question for all possible input documents. I did so for the specific document under discussion. After all, the XSLTBlog assertion would be meaningless ("devoid of content would be more accurate) if you're talking about any other document.
After all, what is the point of saying 'the value of "/a" is not "foo" for some documents'? That is a very close equivalent to what you're saying here.
Except in more complex cases:
Of course I mean "you do not have the sliver of a point".
Except in more complex cases:
I was agreeing with you, in case you didn't notice. I never referred to any of your assertions, I was talking about his:
What I am saying is that there is a text node that is a child node of
emph, whetheremphhas mixed content or not.In fact, you have to spell it
/text()[1]to generate an XPath in the general case, becauseemphmight have mixed content, and thenstring(emph)differs fromstring(emph/text()[1]).(Again, to be abundantly clear: this is an argument in favour of your position not his.)
Except in more complex cases:
sigh. I think this whole indicent occurred so deep in the rabbit whole that I can't even be sure of my own impressions of what I read any more. Sorry for the misunderstanding.
I do hope that after all the dust clears, that the techniques I illustrated in the article stand on their own as useful to someone. I know I've put them to good use (usually after customization to the task at hand) in a variety of circumstances. If a few people do find them useful, I believe all the heat and misunderstanding will have been worth it.
Except in more complex cases:
It's okay. I know what it's like as a generally cool-tempered guy to go through an incidental, atypical outburst, misreading a bunch of things and then feeling sheepish and terribly embarrassed. Don't sweat it.
I liked the article. :-) That is after all why I am supplying an argument in defense of the technique. (I can't use your code verbatim since I'm a devout Perl hacker myself, but DOM is DOM regardless of the language.)