Re: ignorant comments on my most recent O'Reilly article

by Uche Ogbuji

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



7 Comments

aristotle
2004-11-27 19:49:21
Except in more complex cases:
string(/labels/label[1]/quote/emph/text()) in this case is indeed the same value as string(/labels/label[1]/quote/emph), but if that emph tag 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…
aristotle
2004-11-27 19:53:41
Except in more complex cases:
string(/labels/label[1]/quote/emph/text()) in this case is indeed the same value as string(/labels/label[1]/quote/emph), but if that emph tag happens to have mixed content, then it's not. Far from splitting hairs, it's a pretty fundamental distinction.
uche
2004-11-27 20:36:28
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.

uche
2004-11-27 20:40:54
Except in more complex cases:
Of course I mean "you do not have the sliver of a point".
aristotle
2004-11-28 19:26:05
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:


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".


What I am saying is that there is a text node that is a child node of emph, whether emph has mixed content or not.


In fact, you have to spell it /text()[1] to generate an XPath in the general case, because emph might have mixed content, and then string(emph) differs from string(emph/text()[1]).


(Again, to be abundantly clear: this is an argument in favour of your position not his.)

uche
2004-11-28 20:09:56
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.

aristotle
2004-12-02 15:22:56
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.)