Thread: [exprla-devel] RE: [XPL] Hello, and a few comments.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Some excellent input Kurt!  I'll admit, I don't know enough about 
namespaces
right now to fully understand what you are saying, so I will hold off
comments until I get read up on the subject.  However, I will point 
out that
we need to watch the W3C on the namespaces and URI issue before we 
really
get something set in stone over this, unless we plan for whatever
contingencies may result from their final recommendation, or build 
enough
flexibility in to deal with this sort of change in the future.  If I 
am not
mistaken here, we could do the latter using schemas, thus allowing 
updates
now and in the future to be easily integrated without breaking 
anyone's
code.  However, I don't know enough about namespaces right now - 
perhaps
someone can enlighten me further on the issue relating to the problem 
with
the recommendation?

I would also like to note that XPL should be built with the "semantic 
user
interface" in mind, as described this week at www.xml.com, making it 
easy to
write code that allows this to take place ... preferably with XForms,
although I suppose it could just use XML/XSL.  I like the idea of the 
XML
BEING the user interface semantics ... it opens up a whole area to be
explored in user customization.

And finally, I think that we should build XPL to take full advantage 
of the
network protocols enabled by the model which Gnutella offers, 
enabling the
use of COM objects and the like remotely and allowing calls to web 
services
and such technologies coming into being.  Gnutella allows a different 
kind
of communication that will be helpful in many ways; for example, it 
would
allows searches that could search for COM objects on a computer 
somewhere
(not necessarily a server), and leverage it.  Not only that, but 
because
there are probably going to be many instances of the COM objects on 
many
different computers, it would allow XPL to find the fastest location 
from
which to call the COM object, improving performance.  This would also 
allow
us to search for classes, class libraries, methods, functions, 
etc ... by
their descriptions, as defined by Service Description Language, or 
the like
when a component, class, etc ... is missing for some reason - that 
is, it
would allows automatic repair.

We could also use the same methods to evolve the XPL language, by 
somehow
tagging those objects by performance (perhaps store the results in 
databases
... marking them by GUID, so the calling object checks this 
information,
then does a search by Gnutella fashion by GUID - making a failsafe 
method of
finding the object if it exists), using tests which would be created 
by web
services.  Then we could discover the most efficient objects that can
perform the given operation and still yield the best result.  This 
would
serve to evolve the language, and avoid confusion about the best 
methods to
invoke and objects to call.

I think these last few suggestions would make XPL unique (so would 
cross
language transformation and extensibility), in the same way Java was
uniquely built for networks.  Now we have a new networking paradigm 
to work
with.  Let's use it to our advantage.  Let's also figure out how to 
build
security that can deal with this into XPL.

And finally, let's make XPL in such a way, that the programming 
convention
is customizable to a user's mode of thinking ... that is, let's use 
XSLT to
transform the elements and attributes into customizable "analogies".  
Since
I am thinking that this doesn't really explain what I mean, here's an
example:  A computer scientist will be familiar with ideas like 
methods,
objects, functions, etc ....  A biologist works with proteins, 
organelles,
DNA strands, tissue, and so on ....  A chemist thinks in terms of 
reactions,
substrates, molecules, and so on ....  An engineer thinks in 
engineering
terms, and so on.  Can we make it so that people can transform the tag
names, and attribute names, and syntax structure?  Basically, let's 
separate
the function of the syntax from the naming conventions.  This might 
sound
hard, but why not?  Really it is just a transformation over the real
underlying naming convention - the "actual" language is a set in 
schemas,
but can be displayed differently for any users.  Think about how you 
could
alter it to be like your favorite, and your decidely easiest format to
understand - layout operators like in C++, declare variables VB 
fashion, etc
... but it's all XPL really ....

What do you think?

Richard A. Hein

 -----Original Message-----
From: Kurt Cagle [mailto:cagle@o...]
Sent: June 8, 2000 8:29 PM
To: xpl@e...
Cc: Mark Wilson
Subject: [XPL] Hello, and a few comments.

  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.. b.. 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>.
  b.. 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.

  c.. 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.

  d.. 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

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

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