[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: ANN: xpath1() scheme for XPointer


monomaniacal
> 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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.