[exprla-devel] Re: [XPL] Oracle and Sun debut "translets" and virtual machine for XSLT

[reid_spencer <ras...@re...>]

--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
cagle@o... wrote:

Just a quick observation.  I think we need to qualify what is
specifically meant by compilation here, and to note that similar
compiled stylesheets exist on the Microsoft side in the form of
IXSLProcessor entitites.


You're right. It's the first time I've pushed the argument right
through, in my own
understanding. You're a writer, you understand :-)

What's implicit in my exposition is that the usual idea of oompilation
falls apart,
into separate connotations, in the context of XML development.

Here's the definition - and I'll have to stick to it, because it's 
what
most readers
will understand by it:

Compilation is the process which translates a definition of a process,
expressed in
a human-readable source syntax, to a series of instructions in a 
machine
code architecture
which actually carries out the process.

Do we want compilation for XPL, then? NO WAY! People go to all this
trouble to define a
platform-independent syntax for XML - and we propose to give it a
machine-dependent
semantics? We'd have to be nuts.

But, we still want speed, and memory economy. So we're bound to 
propose
something like
compilation, but machine-independent.

There are two dimensions along which we can modify the strict
definition.

(1) We can define a virtual machine architecture, which is similar to
actual machine
architectures, and translate to that. Loosely speaking, we 
can "compile
to JVM bytecode",
for example. Problem solved - provided we include a JVM as part of the
XPL environment.

(2) We can include under the heading of compilation, correctly,
translation to a list
of indirectly-expressed instructions, which is executed in traversal.
Strictly speaking,
this is what we do in (1). But the broadened definition includes
executables such as
Forth - subroutine-threaded code, expressed as a list of subroutine
addresses, with
embedded machine code for a small set of primitives.

(2a) And if we can do that, then why can't we traverse a tree 
structure
of indirectly-
expressed instructions, in memory, in the same form as parsed XML data
trees? It's
only a degree more abstract than (2).

Just where along the line, the mechanism departs from the reader's
understanding of
compilation, is a matter of the reader's background.


Instead of saying "compilation", we should be saying "parsing" for
translation of
source (e.g. paths and templates) to logical tree structure;
"realization" or
perhaps "encoding" for implementation of the trees as instructions on
one of the
models above; and "execution" for the actual transform process.

This may all be clearer once I've researched SAX, and your XPipes.

Jonathan
--- End forwarded message ---