[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ANN: xpath1() scheme for XPointer
> At 5:09 PM -0600 10/26/02, Uche Ogbuji wrote: > > >It's only "completely unambiguous" to you, in the Gospel According to > >Elliotte. I'm having none of your religion. We've had this argument before > >on the hard facts, and you were not able to establish why a processor cannot > >choose to expand XIncludes in processing before it gets to XPath. > > What that argument ultimately came down to was the claim by some > implementers that in processing the original document before making a > transform or applying a transform or querying with XPath, they were > justified in making any changes to the document they felt like; > renaming all the elements to "Ethel" for example, or deleting the > middle third of the document. You're talking complete rot. You quote me where on any mailing list any implementer said such a thing. I said that I can apply XInclude between parse and XPath invocation. You followed up with the reductio that by the same token, in your mind, one could remove sundry parts of documents post-parse. I didn't dignify that silliness with a response. Others, among them people on relevant committees, said that there was no reason why someone couldn't do pre-processing before XPath. That's when you started beating your chest to working groups. > I find that position to be untenable. I think it's contrary to the > language of the spec. And yet you are unable to produce evidence strong enough to knock down even the straw man of your own devising, never mind a more preactical issue of order of XInclude processing. > Unfortuantely, it isn't explicitly stated, > probably because nobody foresaw that people would be so ridiculous as > to make this claim. No one except for you found my position "ludicrous", and there were several who chimed in. Among them a good number of people whose opinion I respect at least as much as yours. > (This is not a theoretical issue. Microsoft, for > one, has repeatedly used this argument to just IE's non-conformant > handling of white space only text nodes.) I think some parts of the > spec do only make sense if you assume the data model/input tree > actually represents the XML document instead of some modified form of > it, but stating this more clearly would be helpful. It would be wrong. XPath should not suddenly gain a coupling to the parsing phase. They are distinct. Your fundamentalism exludes XPath from many of the places where it has been found extremely useful, including invokation from DOM. > > You even > >tried to strong-arm various XML working groups to add "errata" to confirm your > >side of the argument, in direct contradiction of your recent Gospel According > >to Elliotte on spec errata. > > Au contraire, I have no objection to editorial fixes and > clarifications to specs. Since the current language of the XPath > spec is apparently misleading some implementers, it is right that it > be rewritten to be more clear; but it should still say what it's > always said. Conformant XPath processors will still behave the same, > as will nonconformant processors. However, now it will be somewhat > easier to explain to users why certain processor are broken. That's > all. I'm not interested in abstractions here. You said you'd tell people 4Suite and libxslt are broken because they provide the option to expand XIncludes between parse and XPath processing. I'll say again that as far as I'm concerned, you can tell people what you like about my code. I'll continue to tell people that you're monomaniacal and extremely illogical on this matter, and that you also have the unfortunate complementary problem of being dead wrong. And BTW, you should know that "conformant XPath processors", even by your own unsupported definition sill not behave the same, because some will process DTDs and some won't. And that a given "conformant XPath processor" will even behave differently on the same document in some cases, depending on whether or not entities are found for resolution. I suppose your next step will be to demand an erratum for XML 1.0 closing the optional DTD and entity reolution error acceptance. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p y.html The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind ex.php/article/articleview/663/1/24/ The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in dex.php/article/articleview/679/1/24/ Serenity through markup - http://adtmag.com/article.asp?id=6807 Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork s/xml/library/x-tipgenr.html
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|