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

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

--- In xpl-dev@y..., cagle@o... wrote:
Jonathon,

I was basically stumbling tired yesterday, or I would have responded 
more cogently on this.

I personally don't think you'll see "one" language emerge under the 
rubrick of XPL. Rather, I sense that we're talking about a 
methodology for creating languages within the constraints of an XML 
environment, and that, just as there are multiple procedural 
languages that have already filled their respective niches (you 
wouldn't program low level system components with Visual Basic, nor 
would you write high level "Business Logic" with C++), that we'll see 
analogous low and highl level XML based languages, many based upon 
some variation of XSLT.

The way I'm handling XPipes (which I really hope to get up to the 
VBXML site sometime this week), is that it is essentially an 
uncompiled language that is then processed into XSLT. I liken it to 
the Java model --> the original source code is first compiled into 
the java bytecode, which is then interpreted using the Java virtual 
machine into a binary representation.  XPipes works on a similar 
premise: XPL Precompiled code --> XSLT Raw code --> XSLT Compiled 
code. The difference between these is that whereas the Java VM is an 
event driven message loop environment (is stateful), XPipes is 
stateless and is driven by the movement of streams.  That's not to 
say that you couldn't create an even driven version of this in a 
client environment (a stream of XML triggers a series of events 
within the XPipes message loop which in turn cascade into responses), 
but the model assumes that most of the code there is still XSLT 
specific.

One of the goals that I have for XPipes and similar XPL languages is 
that they serve as testbeds or catalysts for the XSLT2 developments. 
XSLT is Turing complete, but its also a language with some gaping 
holes. It's scoping model is rather skewed, you have to create 
multiple recursive instances of for-each loops to handle indexed-for 
expressions, it really does need regular expressions as an integral 
part of XPath (why they took it out is beyond me, that was the first 
thing to make sense in XSLT for me in a long time). The binding 
between XSLT and XML Schema needs to be written. There needs to be a 
much tighter story for module deployment standards (otherwise we have 
this proliferation of procedural scripting languages to handle the 
shortfall, reducing interoperability and adding to the general 
headache of developers). 

I would agree with you, though, on the notion that compilation in and 
of itself for any XSLT language is a local rather than a global 
thing. I view an XSLT stylesheet as a filter which takes one or more 
incoming XML streams and creates zero or more outgoing XML streams, 
though it may in the process perform some side effect that is the 
actual desired result (much as a function may take information to 
blit an image to a screen and then return an error code as a result --
 the error code is very much secondary to the blitting, but the 
blitting is effectively just a side effect). In short, there is a 
fairly high degree of correspondance between  an XSLT stylesheet and 
a compiled function.  Making the jump to the next level of 
abstraction -- between a stylesheet and a component -- is a more 
sophisticated process, but certainly doable; however, in this case 
you're effectively talking about the "methods" potentially spanning 
more than one computer, as would the component itself. In this case, 
the methods may be compiled, even though the component itself is most 
certainly not (it in fact exists not as a discrete entity but rather 
a pattern of actions). 

I think we're going to find this to be the case with a number of 
elements that have traditionally been compiled -- the compilation 
process creates a tightly bound entity, whereas XML tends to create 
decoupled systems, much more loosely bound than is traditional with 
procedural languages. This will in turn force us to reconsider out 
paradigms, and look more closely at the nature of programming across 
distributed systems. I think the results will be much more organic 
and self-organizing than procedural programming will, but I'm not a 
hundred percent sure of this.

-- Kurt Cagle


  ----- Original Message ----- 
  From: Jonathan Burns 
  To: xpl@e... 
  Sent: Sunday, June 25, 2000 4:57 PM
  Subject: Re: [XPL] Oracle and Sun debut "translets" and virtual 
machine for XSLT


  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 
    
    
    
    
    
  To unsubscribe from this group, send an email to:
  xpl-unsubscribe@o...
--- End forwarded message ---