[exprla-devel] Direction and purpose of XP

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

--- In xpl-dev@y..., cagle@o... wrote:
I'd like to add a few comments to this:

I think Jonathan sums up the situation very nicely. One of the things 
to consider with XML is that it is not a technological standard. I 
know this sounds counterintuitive but lets face it, XML is a fairly 
indifferent data format, something that's existed for several years 
in slightly more arcane form.  Rather, XML is a political standard. 
It is an agreement between a large and growing number of people to 
use the syntax and grammar that's presented in the XML standards 
document as the basis for data communications.  This holds true for 
XSLT and will hold true for schema as well. Already, I'm seeing 
situations where companies that attempt to deviate from these 
standards (Microsoft comes to mind) discover that while they can 
build a better version, it is not a version that people will end up 
using because it isn't standard. This is very different from the 
situation from HTML, largely because there wasn't the pushback from 
the community to maintain the data standards in the same way.

XSLT is a transformative mechanism, and moreover is the accepted 
transformative mechanism for XML streams. It is actually very good at 
what it needs to do, but suffers somewhat from the limitations 
imposed by being a language designed by commitee. There are 
provisions in XSLT for extension, however, and these provisions 
should be used in any solution built around XSLT. I have built 
message board systems and have seen Outlook like applications that 
were built largely with XSLT. With XSLT you can generate SVG output 
to handle graphics, can transform MathML to handle equation 
processing, can (with extensions) handle multiple streams both for 
input and output, and so forth.  

Consider the need for programming languages in general. Creating a 
language like Basic in XML would be somewhat counterproductive -- you 
can write VBScript code and use the DOM for that. To modify Basic so 
that it can be rendered in XML ends up creating the worst of both -- 
the verbosity of XML combined with the sometimes wildly inconsistent 
representations of commands in VB.   If the purpose of the language 
is to perform transformations on XML streams (keeping in mind that 
setting the state of a device is as valid a transformation as setting 
a variable) then XSLT will get you 80% there.  By incorporating a 
script that can work effectively as an integrated element within XSLT 
you can concentrate on the remaining 20% without having to redefine 
transformations from the get go: manipulating object references, 
performing input/output to devices, event handling, and working with 
functional definitions.

One of the biggest problems that XSLT has (and one that I'm lobbying 
the W3C to change) is the fact that there is no way to create a 
functional reference to a named template. I'd love to see something 
like:

<xsl:template name="myFunc">
     <xsl:param name="param1"/>
    <!-- do something here -->
</xsl:template>

<xsl:value-of select="myFunc('myPassedParamValue')"/>

This is one area where I can see an XPL like piece working, because 
it could act as the bridge to do this (you actually can generate one 
from the other, but the actual XSLT for the functional output mirrors 
the input:
<xsl:variable name="myFunc_call">
    <xsl:call-template name="myFunc">
        <xsl:with-param name="param1" select="'myPassedParamValue'"/>
    </xsl:call-template>
</xsl:variable>

<xsl:value-of select="$myFunc_call"/>

One way that I can see developing XPL would be to create a set of 
associated objects that might be written in Java or script, then put 
XML wrappers around them and use the extensions from XSLT to 
incorporate them. By creating a set of these code components, you can 
essentially start developing an API, which is I think where XPL 
offers the greatest benefit. That way, you could, taking a cue from 
my note yesterday, create an XP routine that could, as an example, 
output an integration graph:

<xp:with object="math">
<xp:for var="x" start="0" increment=".01" test="$x &lt;= 1.0" 
xsi:type="float">
        <xp:var name="y" value="sin($x)*cos(3*$x)*exp(-sqr($x*.025))" 
xsi:type="float"/>
        <xpo:graphics method="draw_rect" left="{100+$x*200}" 
bottom="200" top="{$bottom-200*$y}" right="{$left+$x*199}" 
style="background-color:green;border:none;"/>
</xp:for>
</xp:with>

Here there are in fact four distinct objects present -- the math 
object, which defines operations like sin(), cos(), etc., the 
graphics object, which includes the draw_rect method, the xp object 
which handles the language definitions, and the xsi: object, which 
handles the XML Schema instance interface for defining datatypes. The 
syntax presented here is not all that different from a VB script, 
either.  The same code written in VB (assuming that VB had a distinct 
math object) might look something like:

with math
    dim x as double
    dim y as double
    for x=0 to 1.0 step 0.01
        y=sin(x)*cos(3x)*exp(-sqr(x*0.25))
        graphics.draw_rect.left=100+x*200
        graphics.draw_rect.bottom=200
        graphics.draw_rect.top=graphics.draw_rect.bottom-200*y
        graphics.draw_rect.right=graphics.draw_rect.left+x*199
        graphics.draw_rect.style="background-color:green;border:none;"
    next
end with

Nice thing is that the code there could easily be dropped into an 
XSLT script. For instance:

<xsl:template name="draw_integration_chart">
    <xsl:param name="equation"/>
    <xsl:param name="start"/>
    <xsl:param name="end"/>
    <xsl:param name="delta"/>
    <xp:with object="math">
      <xp:for var="x" start="$start" increment=".$delta" test="$x 
&lt;= $end" xsi:type="float">
        <xp:var name="y" value="$equation" xsi:type="float"/>
        <xpo:graphics method="draw_rect" left="{100+$x*200}" 
bottom="200" top="{$bottom-200*$y}"         
                              right="{$left+$x*199}" 
style="background-color:green;border:none;"/>
       </xp:for>
     </xp:with>
</xsl:template>

<xsl:call-template name="draw_integration_chart">
    <xsl:param name="equation" select="sin($x)*cos($x)"/>
    <xsl:param name="start" select="0"/>
    <xsl:param name="start" select="2"/>
    <xsl:param name="start" select="0.02"/>
</xsl:call-template>

Since XPL wouldn't modify the XSLT, things like the $equation would 
automatically get expanded before the XSLT even saw it.

The biggest challenge that I can see to a declarative XPL model comes 
in an event based environment -- the XP language that I've been 
discussing works in a largely declarative fashion -- stream comes in, 
an XP generated XSLT script processes the data, output stream(s) are 
sent on. I think eventing mechanisms are possible, but I'm still 
trying to figure out the most efficient way of handling things like a 
mouseclick (i.e. client side issues).  In an ideal XP "browser", an 
event would send an XML stream to an object script that would trigger 
a set of default XP templates:

<event id="onclick" timestamp="2000-06-10T12:15:24" window="main" 
x="120" y="169"/>

<eventhandlers>
    <when test="@id='onclick'">
        <exec select="xpo:this!image_whack(@x,@y)"
    </when>
</eventhandlers>

where xpo:this would contain a reference to the object receiving the 
event and the default namespace is the xp: namespace. Thus, when the 
object is clicked, this.image_whack(120,169) would be called. 

The event handler processors would have to be supported by some code 
in the background. In other words, an XP client would probably run as 
a Java applet or ActiveX object within an XML browser page, although 
conceivably down the road this could be incorporated directly into 
the browsers.

Sorry for the code intensive response here. I see an XML programming 
language as a logical (and necessary) next step to building more 
sophisticated applications (I'd like to eliminate Java AND COM 
eventually <grin/>). By keeping it object oriented and modular, it 
gives the language the capability of adding components directly from 
the Internet. Note though that in this approach, the language is 
assumed to be largely an integration language along the lines of VB 
rather than a highly efficient processing language like C++. Some 
components may be written in XPL (or XSLT), some components may be 
external COM or Java Classes, some components may be mixtures of the 
two.  Of course, there's nothing that says you couldn't build an XPL 
class that generated code that could be fed into a Java compiler -- 
that's one of the beauties of XSLT.

Also, about MathML -- MathML is a markup language for describing both 
the visual representation of mathematical equations and the 
conceptual underpinnings of these equations.  It doesn't actually 
contain any code for the interpretation of equations -- this would 
have to be handled by a third party component.  However, there's 
nothing that says that an XPL class couldn't do just that, converting 
a MathML stream into a functional representation of that stream; 
indeed, since the language is basically a pre-processor language that 
would mean that the MathML representation would be conceivably 
encoded as a binary executable at that point, which would make it 
very efficient. 

-- Kurt Cagle

----- Original Message ----- 
  From: Jonathan Burns 
  To: xpl@e... 
  Sent: Friday, June 09, 2000 7:40 PM
  Subject: Re: [XPL] Hello, and a few comments.


  Kurt, thanks very much for this thorough review - and for the 
invitation. 
  To my fellow contributing members of the XPL list over the past few 
weeks: 
  I'm going to say something rather geeky here, but I think it's 
important. 

  Kurt's post is a turning-point for the list. Up til now, it's been 
reasonable 
  to see ourselves as working out a complex possibility on our own 
initiative, 
  with our own resources, and within our own limitations. Which, let 
us face it, 
  are considerable. To speak of my own, I'm a raw beginner at even 
the basic 
  Web technologies (still have yet to write a non-trivial CGI 
program); and I'm 
  desperately looking for work, which when I find it will almost 
certainly 
  knock the stuffing out of my concentration time. 

  Within our limitations, I'd say we've done pretty damn well. We've 
managed to 
  canvass a lot of possibilities for what XPL can be and do. We've 
identified 
  the major technologies where we can expect to find implementational 
power, 
  and also integration with the wider XML community. Not least 
important, we've 
  built up a sense of community, where everyone's contributions are 
reoognized, 
  and nobody is discounted, e.g. for being a Web newbie. 

  That last one is extremely valuable to me. XPL is where I get to 
articulate 
  ideas which come out of a quarter-century of experience, especially 
in 
  computer science, which don't seem relevant or welcome in any other 
context. 
  There isn't anywhere else quite like XPL, for me. 

  Now we're being challenged in a sense, to take off the water-wings 
and dive 
  in at the deep end; where there are people like Kurt who have been 
three 
  years at the cutting edge. 

  Compared to what the W3C/XML community are doing, implementing 
QBasic or 
  Miva as XML documents are very limited goals. I can see larger ones 
in 
  principle - but the limited goals are something we could 
realistically 
  achieve. 

  Now personally, I like the way that Alexander, Richard and now Kurt 
are 
  raising the stakes. It has already become clear that the whole 
gamut of 
  XML accessories - Xpath, Xlinks, the DOM, XSLT and more - 
enormously 
  extend the answers to the questions, What can we do with and to XML 
  documents? They may turn out to BE the answers - and they may make 
the 
  whole concept of XPL as a distinct language irrelevant in the end. 
  Whatever, we will inevitably have to integrate XPL's desing goals 
with 
  them, as Kurt says. 

  I just think - here's the geeky bit - that in a real sense this is 
Michael 
  Lauzon's group. XPL is his inspiration, he got discussion started, 
set up 
  the forum, and is going to some trouble to maintain it. That 
doesn't make 
  him the boss, or right about everything, but to me it gives his 
views 
  some special authority. 

  Meaning, that if Mike thinks we should remain an affiliated but 
distinct 
  group, working toward a limited, but definite and achievable goal, 
then 
  I would support that. As far as I could, I would contibute to XPL 
and 
  VBXML both; but I would put my priority effort in making sure that 
this 
  group survives, more or less as it is. 

  On the other hand, if Mike thinks we can get further by casting our 
lot 
  with VBXML, I think it would be about ideal - with this 
qualification: 

  I need there to be a zone which is newbie-friendly. Some place 
where 
  the dumb questions are asked, and the answers spelled out. And 
nobody 
  is frozen out because they can't follow the jargon. And everybody 
gets 
  respect. If I have to moderate it myself. 

  See, I think that the XML technologies are ultimately simple. XML 
was 
  designed to be, and that accounts for much of its rapid spread. I 
could 
  teach it to high-school kids. But, there is always the tendency to 
  speed the discussions with shorthand that turns into private 
jargon, 
  or with high computer-science abstractions, which are already 
pretty 
  cryptic. And that will freeze newcomers out, unless there is a 
special 
  effort made to maintain clarity, and to keep the bridges open 
between 
  the general community and the cutting edge. That special effort is 
my 
  forte - and that's where you'll find me, if necessary at the 
expense 
  of my participation in some of the advanced efforts. 

  Goodwill 
  Jonathan 

  "Oh god. This job application's been a whole year in process!" 

  "Happy birthday to you, happy birthday to you..." 


----------------------------------------------------------------------
--------



----------------------------------------------------------------------
--------
  To unsubscribe from this group, send an email to:
  xpl-unsubscribe@o...
--- End forwarded message ---