[exprla-devel] Hello, and a few comments.

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

--- In xpl-dev@y..., "Kurt Cagle" <cagle@o...> wrote:
Just a brief introduction. My name is Kurt Cagle, and I am a writer 
and programmer specializing in XML related issues. I was one of the 
starting writers for Fawcette's XML Magazine, and have written books 
for Microsoft, Wrox, Coriolis and Sybex on XML. I'm currently working 
on the XSLT documentation for the MSDN website. I'm a fair VB 
programmer (I've written a book VB and web technology) but I've 
basically been living, eating and breathing XML, XSLT and XML Schema 
for the past three years.

I was forwarded the xpl address by Mark Wilson, and am writing to get 
involved with what is happening here. I want to second his comments 
that VBXML is made up of a number of developers that are dealing with 
programming XML at any number of different levels -- the VB side is 
very much secondary to the XML side. I would heartily recommend that 
you bring the superb discussion I've seen thus far into VBXML -- I 
think it would be invaluable for making XPL a viable language.

Concerning XPL, I'd like to add my two cents worth into the 
discussion -- one of the things that I've been doing with Mark is 
putting together an XSLT based framework, and XPL seems like a good 
place to explore in attempting to put this together. 
My own sense of the programming language interface that needs to be 
addressed involves a number of different aspects:

  a.. XLST Integration. XSLT is the programming language for XML. Any 
XPL language needs to recognize this as a central tenet. As I see it, 
the language should be something that can exist as a namespace 
addition to XSLT, which has a basic (albeit currently somewhat crude) 
mechanism for extending XSLT itself. James Clarke's XT contains hooks 
for Java through a namespace, and the MSXML3 parser lets you both 
create objects and instantiate existing COM objects (sort of) through 
the same mechanism.
  b.. Declarative vs. Procedural Programming. XSLT is fundamentally 
declarative, even in its use of named templates and parameters. The 
temptation to make the XPL language procedural is pretty strong, but 
I would personally argue that it is one that needs to be resisted.  
Procedural programs tend to encourage statist thinking, work best for 
synchronous (local) communication, and can already be readily 
emulated with languages like JavaScript. Any XPL language should be 
largely syncretic -- it should be possible using XPL to create other 
XPL programs dynamically, because one of the real strengths of XSLT 
(one that hasn't been explored yet) is that XSLT allows for the 
creation of code through automated processes.
  c.. Multi-pass compilation. One of the things that I'm doing with 
the XMLPipes framework that I'm writing is to view the XP code as 
being the easier to author source code that is in turn compiled into 
XSLT transformations that can be handled by existing processes. The 
compilation is itself handled through an extended XSLT 
transformation -- the source code, being an XML document, would tell 
the XSLT compiler to introduce external XSLT stylesheets that contain 
specialized code. This code that is created would then consist not of 
a single XSLT document, but rather an XSLT document that contains 
import code for other XSLT filters. One advantage to this approach is 
that a number of the major XML parser designers include the ability 
to compile and persist XSLT as binary objects, making them much more 
efficient for scalability purposes.
  d.. Object Oriented. This goes without saying. Something that I've 
been playing with has been the development of object oriented XSLT 
filters -- you create an instance of an object, such as a Table 
Filter, that can take a data stream and additional elements as 
parameters as well as an action parameter that determines the method 
to be invoked:
<xpo:table_filter action="display_wml_format" source="$my_stream" 
output="new_table"/> 
  a.. This call would take the contents of the $my_stream variable, 
apply the display_wml_format in the table_filter object, then place 
the resulting xml into a new variable called $new_table.  This might 
be first pass transformed into an XSLT script looking something like:
<!-- in the header -->
<xsl:import href="table_filter.xsl"/>

<!-- in the body of the transform -->
 <xsl:variable name="temp_1">
     <xsl:call-template name="table_filter">
         <xsl:with-param name="action" 
select="'display_wmil_format'"/>
         <xsl:with-param name="source" select="$my_steam"/>
     </xsl:call-template>
</xsl:variable>

<xsl:variable name="new_table" select="node-set($temp_1)"/>
  a.. Of course, if no output attribute existed, then the contents 
from the call would go directly into the default output stream. An 
alternative functional form might also be possible:
          <xp:out>xpo:table_filter!display_wml_format($my_stream)
</xp:out>
  a.. which would send the contents directly to the output stream. In 
this case, xp: is the XML Pipes native namespace, while the xpo: 
namespace corresponds to XML Pipe Objects. This could even be 
simplified further as:
<xp:with object="xpo:table_filter">
    <xp:out>display_wml_format($my_stream)</xp:out>
</xp:with>

a.. which corresponds roughly to the VB With keyword, assigning a 
given object as the scope of all functions for the duration of the 
with statement.
  a.. a.. Add constructs rather than create one from whole cloth. You 
can do a fair amount already with XSLT. If XPL is to succeed, it 
should add constructs that add functionality to XSLT -- it'll make it 
easier to adopt, make it easier to templatize, and will allow you to 
incorporate XSLT calls within your XPL script (the first pass 
transformation would simply adopt a different namespace designation 
for the XSLT keywords, a common enough practice).  For example, it 
would be useful at times to include an indexed for to the for-each 
statement that currently exists:
    <table>
        <xp:for  start="1" index="i" test="$i &lt;= 20">
<row>
    <cell>{$i}</cell>
    <cell>{$i*$i}</cell>
</row>
        </xp:for>
    </table>
This would end up creating a table iterating from 1 to 20 inclusive, 
with the value and the square of the value in contiguous cells. 
Again, though this would be post processed into XSLT, which would 
probably have to do a structure like:

<xsl:template name="for">
    <xsl:param name="i" select="1"/>
    <xsl:param name="increment" select="1"/>
    <row>
        <cell><xsl:value-of select="$i"/></cell>
        <cell><xsl:value-of select="$i*$i"/></cell>
    </row>
    <xsl:if test="$i &lt;=20">
        <xsl:call-template name="for">
            <xsl:with-param name="i" select="$i+$increment"/>
            <xsl:with-param name="increment" select="$increment"/>
    </xsl:if>
</xsl:template>

By doing this, you replace a complicated structure with a much 
simpler one without having to write a parser that handles the 
internal task of iterating. Note also the use of the XSLT bracket 
elements {} to handle evaluation of content into the output stream. 
This is essentially the same as <xp:out></xp:out>.
a.. Use XPL calls for handling external objects. One of the areas 
that involves the biggest amount of work would be an extension that 
would let you communicate with external objects. By hiding it behind 
an xpo: namespace, you could hide the differentiation between 
internal objects and COM interfaces:

<xp:declare_new_object name="fso" href="Scripting.FileSystemObject" 
type="COM"/>

<xp:exec cmd="fso:createTextFile('NewFile.txt',2)" var="txtfile"/>

<xp:out>$txtfile!ReadAll()</xp:out>

This would create a file system object (a COM object), would execute 
the method createTextFile on the object and assign the handle to the 
$txtfile variable, which could then call the RealAll method and 
output the results into the output stream.

a.. Pass server variables in as parameters. Much of XSLT involves 
parameterization of form or query string data. Variables can be 
declared within XP that automatically fill with the server variable 
if it is passed:

<xp:query var="page"/>
<xp:query var="item_number"/>

For the query string "mydoc.xp?page=4&item_number=6" then this will 
be converted into:

<xsl:param name="page" select="4"/>
<xsl:param name="item_number" select="6"/>

Since the XSLT is compiled afterwards itself into a binary, the page 
and item_number parameters can be set through DOM calls at some later 
point. Additionally, server variables such as QUERY_STRING are 
automatically added to the list of available parameters, so that you 
could use $QUERY_STRING as an expression without having to explicitly 
declare it.

a.. Verbosity. XSLT is verbose in part because of the use of 
namespaces, and in part because the architecture favors the use of 
recursive structures over procedural ones, which in turn tends to 
stress template blocks that can get hideously complex.  However, 
using a two pass architecture you can turn a significant amount of 
your code into either tag and attribute forms, or executable line 
calls. You could even create multiline script blocks using this 
architecture, since the code will be converted into XSLT that would 
be manipulatible:

<xp:for index="i" start="0" test="$i &lt; 20" output="$sum">
    <xp:var name="j" init_value="0"/>
    <xp:var name="sum" init_value="0"/>
    <xp:script>
    $j=$j+$i;
    $sum=$sum+$j;
    </xp:script>
</xp:for>


While this is a little more complex that the equivalent procedural 
code, it's not that much worse:

function sum(){
    var j = 0;
    var sum = 0;
    for (i=0;i<20;i++){
        j=j+i;
        sum=sum+j;
        }
    return sum;
    }

These are just a few thoughts on the issue. In the main, I would 
suspect that if XPL can stick closely to the XSLT/XPath 
specifications, enhance rather than replace functionality, and work 
with a dual path architecture that will transform the XPL into a 
compiled XSLT form (a la the MS Processor object) it will make for a 
far more flexible language.

Kurt Cagle
XML Pro, Fawcette/DevX
cagle@o...
(360) 951-6159
--- End forwarded message ---