The spirit of XML (was RE: [xml-dev] Re: I can XInclude where I [expletive deleted] wantto)

Elliotte Rusty Harold wrote:
> >XSLT processors do not build source trees, so the question doesn't arise.
> >
>
> In other words anything that happens before the source tree is
> created is completely legal, no matter what. If I feed an XML file
> into Saxon, and Saxon changes all my rectangle elements into circle
> elements before it constructs the source tree, I have no claim that
> Saxon is nonconformant. That's a pretty radical interpretation of
> XSLT.

No, just a literal interpretation. By the letter of the law, you can't claim
otherwise. Until we have an unambiguous XML processing model spec with clear
conformance requirements (somewhat of a holy grail), it will continue to be
that way. But we're humans and can make judgments about whether particular
practices violate the *spirit* of the law. Various examples come to mind.

I think that XInclude processing in the context of 4XSLT is perfectly fine,
because 4XSLT provides an API to unset that flag. Ideally, there should be a
flag to turn off xml:base processing as well, but I don't see that as nearly
as important. (It's hard to imagine cases where you use xml:base but want to
be blind to it, even from within XSLT, especially since the document()
function allows you to override the base URI by passing in a different node
as the second argument.)

I'm not sure if MSXML provides the ability to turn whitespace-stripping off;
whether it does or not, the fact that it's the default for
XSLT-in-the-browser seems to violate the spirit of the XSLT specification
(if not the letter), because then I can't reliably send a stylesheet to
different browsers and expect it to work uniformly. Unlike a server-side
context where I have full control over my XSLT processor's various
parameters, the only means of communication I can possibly have with the
browser is the XSLT stylesheet (unless I resort to using non-standard
browser scripting). Perhaps a processing model specification should have a
separate document or section devoted to Web browsers.

This discussion has been about whether some existing XSLT processors do more
than they should when it comes to parsing-and-tree-building. One of my
complaints is that they still do *less* than they should (again, by the
spirit of the law). Let me explain.

The XSLT data model supports source trees and result trees that correspond
to any external general parsed entity, not just well-formed XML documents.
I'm still waiting to see an XSLT processor that comes with a parser that
supports this (someone please point me to one if it exists). All of the XSLT
processors I know of, if they come with a parser, come only with an XML
parser, but clearly more than just an XML parser is needed to support the
full range of input. I want to be able to access the EGPE source tree like
any XML document source tree, e.g. on the command-line. That way, I can
reliably do pipes of transformations mixed in with other kinds of
transformations, taking full advantage of XSLT's closed data model. And I
assume this code has been written, as it's an important subprocedure in XML
parsing.

Finally, along the letter vs. spirit lines, I think of SOAP's rejection of
any kind of DOCTYPE declaration (assuming it's still that way). By the
letter of the law, it's hard to argue that this constraint is any different
than requiring elements to have particular content models, or attributes to
have particular types. However, given the precedent of existing practices
and W3C specs and data models, I think this violates the spirit of the
law--particularly because it allows and even encourages the use of SOAP
parsers (as opposed to XML parsers) and applications and APIs that only
understand SOAP parsers, thereby precluding the possibility of swapping in a
different XML parser at any time. (After all, if processing halts at a
syntax error, why should I bother writing error-checking code at a higher
level?) Indeed, I get the feeling that the reason for this constraint's
presence is to accommodate existing SOAP applications that only know how to
talk to SOAP parsers (again, as opposed to XML parsers).

Evan