OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] ANN: xpath1() scheme for XPointer

[ Lists Home | Date Index | Thread Index ]

At 10:14 AM -0700 10/27/02, Uche Ogbuji wrote:

>You're talking complete rot.  You quote me where on any mailing list any
>implementer said such a thing.

The change of the xinclude:include element to a different set of 
elements is no better and now worse than changing any other element 
to any other group of elements. If one's legal, the other's legal. Of 
course nobody jumped up to say that,"Yes, yes, it is so wonderful 
that we can change all the element names to Ethel and still be 
conformant" because nobody wants to do that, and it makes absolutely 
clear just how big the problems are that your interpretation of the 
spec leads to. But I don't think anybody denied it either. Do you 
want to deny it? Can you show me the language in the spec that says 
it's OK to replace XInclude elements with other elements, but it's 
not OK to change all the element names to Ethel?

I admit I that I brought up this argument in the expectation that its 
sheer ridiculousness would get some people to back off of their 
positions. I was surprised to see that they did tenaciously hold on 
to their position, even as their position was pushed right over a 

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

No, I'm perfectly willing to use an XPath on a DOM. However, if the 
document is parsed in from a file into a DOM, the DOM is then 
changed, and the changed DOM is queried or transformed, then that 
process is not operating on the original document. It's operating on 
the new, changed, document, which is fine, if that's what someone 
wants to do.

What's not fine is for a tool that advertises itself as an XSLT 
transformer or an XPath querier that operates on XML documents found 
at particular URLs to make changes to those documents before 
transforming or querying them. Whatever internal representation the 
tool uses for the actual XML document that the user gave them must 
faithfully represent the original document. If it changes that 
document by replacing or renaming elements, then it is not querying 
transforming the original document. It is transforming or querying a 
different document that may perhaps be related to the original 
document but is not the same thing.

>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 have no objection to an option. I object to changes that are made 
by default without a specific user request. When a user passes an XML 
document to libxslt, IE, or 4suite they have a reasonable expectation 
that this tool will transform the document they gave it according to 
the stylesheet they gave it. It is not OK for these tools to decide 
they want to make additional transformations the user did not ask for.

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

That's a whole other thread. My opinion is that an XSLT processor or 
XPath query tool that encounters a skipped entity  should choke, 
whatever that means in the local environment. The XPath data model 
does not include skipped entities, so I don't see anything else that 
can be reasonably done here.

| Elliotte Rusty Harold | elharo@metalab.unc.edu | 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/    |


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS