[
Lists Home |
Date Index |
Thread Index
]
> 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
|
