[
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
cliff.
>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/ |
+----------------------------------+---------------------------------+
|
