RE: Why are there no XSLT processors implemented in XS

> -----Original Message-----
> From: David Carlisle [mailto:davidc@xxxxxxxxx]
...
> On 01/05/2012 12:49, Costello, Roger L. wrote:
...
>

A:

> Why would anyone even try to do this, even if it were possible, it
> would be vast amounts of work and would just produce an xslt engine
> that is slower than the one you started with.
...

B:

> Because it is not a good language for writing a compiler or parser. It
> is a good language for processing XML.
...

David -- Your views seem to be in some tension.

Given that XSLT processors must be able to process (1) XSLT, which is XML, and
(2) input files, also in XML, it seems that A implies that B is wrong--that
is, it implies that XSLT is not in fact always a good language for processing
XML.

Roger -- Consider whether SQL processors are normally written in SQL, or unix
shells in the languages they define.

Some languages work for writing their own compilers/parsers/execution engines,
while others don't. Some reasons:
* Purpose of the language: specialized or broad? What is it good for, and not
good for?
* Whether the design of the language permits the kind of subsetting that is
needed for the compiler bootstrapping

Doubtless there are other factors.

Your original conclusion ("For real, manly XML processing don't use XSLT;
instead, use Java.") is dubious primarily because its wording is vague and
combative. Rephrase it as follows, and it's clearly true:

Some XML processing problems are best solved in XSLT; others aren't.

The interesting question is which are which--which I'm sure is the question
you were getting at.

Norm