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

Re: ANN: xpath1() scheme for XPointer

• To: Uche Ogbuji <uche.ogbuji@f...>
• Subject: Re: ANN: xpath1() scheme for XPointer
• From: Elliotte Rusty Harold <elharo@m...>
• Date: Sat, 26 Oct 2002 19:38:20 -0400
• Cc: xml-dev@l...
• In-reply-to: <E185a4F-0002ln-00@m...>
• References: <E185a4F-0002ln-00@m...>

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.

I find that position to be untenable. I think it's contrary to the 
language of the spec. Unfortuantely, it isn't explicitly stated, 
probably because nobody foresaw that people would be so ridiculous as 
to make this claim. (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.

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

This is very different from the some of the changes that have been 
made to Namespaces and XML 1.0 itself, where there was never any 
confusion over what the spec said or meant; but the editors 
nonetheless chose to change the definition of the language without 
following the advertised W3C process for making such changes. This I 
very much object to.

-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@m... | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

• Follow-Ups:
  • Re: ANN: xpath1() scheme for XPointer
    • From: Uche Ogbuji <uche.ogbuji@f...>

• References:
  • Re: ANN: xpath1() scheme for XPointer
    • From: Uche Ogbuji <uche.ogbuji@f...>

• Prev by Date: Re: Are XML's Good Ideas hidden? (was Re: Re: What are Sc...
• Next by Date: Re: ANN: xpath1() scheme for XPointer
• Previous by thread: Re: ANN: xpath1() scheme for XPointer
• Next by thread: Re: ANN: xpath1() scheme for XPointer
• Index(es):
  • Date
  • Thread