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

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

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

  ----- Original Message ----- 
  From: Richard Anthony Hein 
  To: xpl@e... 
  Sent: Thursday, June 08, 2000 11:48 PM
  Subject: RE: [XPL] Hello, and a few comments.


  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've actually been thinking about the schema issue quite a bit.  
Schemas provide an interesting mechanism for defining type both at 
the simple and the complex level.  Thus, I could actually scoping out 
the type of a variable before assigning it -- a simple case being 
something like:

<xp:define name="item_count" xsi:type="nonnegativeInteger"/>

while a class instance could utilize predefined object types:

<xp:define name="window" xsl:type="Window_Class"/>

Namespaces are generally viewed as necessary evils in XML -- they 
have just moved too far with namespaces in place to effectively walk 
away from them now. If they do in fact change the namespace 
recommendation (and there are some serious flaws, especially in the 
area of XSLT) then I think that XPL could still largely recover -- 
the question of differentiating the namespaces is still too critical 
an issue.

  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.
It sounds like it might be worth differentiating between XPL and the 
XPL IDE. Visual Basic, for example, is a language -- a set of 
keywords that can be used to tie component architectures together.  
Visual Basic is also an IDE, and this has the drag and drop elements, 
the script windows, the object palettes, etc.  For clarity, let's 
keep the language architecture itself called XPL, while the interface 
description language could be called something like XPLODE (XML 
Programming Language Object Definition Language). 

There's no reason why you couldn't incorporate XForms into your XSLT 
architecture -- XForms basically describe the characteristics of the 
form, while XSLT can be used to generate or populate such forms (I 
actually have an XSLT template that does something very similar). The 
XPLODE interface in general would be one that was specifically not 
tied into a given browser -- it would describe icon elements, 
buttons, and so forth, but would do so in such a way that an Opera or 
Netscape 6 or IE 5 browser would all be equally capable of being used 
to host the IDE. In essence XPLODE provides the metadata that would 
then be transformed to create appropriate skins for the respective 
browsers.

One additional benefit to following this approach is that you can use 
the browser as your IDE to develop your code, making it ideal for 
working over distributed environments. I'd like to see some form of 
an XMLHTTP like component that would also let you communicate 
directly with the server -- which would presumably be a Java applet 
on the Netscape/Opera side and the XMLHTTP component on the IE side. 
Thus, you'd need to have a fairly powerful browser to handle the 
production of code, but it wouldn't necessarily rely specifically on 
one implementation of that code.
  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.  
 I'd be VERY careful about this. The Gnutella approach is intriguing, 
but it relies too much on the off chance that someone would be dumb 
enough to expose COM objects in the open. MP3s, yes. DLLs, not a 
snowball's chance in hell.  If I can make a couple of proposals here -
- Sun has become the third major player (after Microsoft and IBM) to 
adopt the use of SOAP as a distributed language protocol, and I 
suspect that SOAP servers will become commonplace on Linux boxes as a 
consequence. I'm not wild about SOAP from a conceptual standpoint, 
but I will readily admit that if the PTB all decide to make SOAP 
available, I'll use it. SOAP servers include a mechanism for 
discovery that is XML based, obviating the need for messing with 
other protocols besides HTTP, and SOAP isn't under legal fire in the 
same way that Gnutella is. Now, that doesn't mean that we couldn't 
combine a Gnutella like search with a SOAP interpreter...

Another advantage to SOAP is that it is language neutral -- you can 
create a SOAP query against a Java object just as readily as you can 
against a COM object. It also provides an interface for handling data 
into SQL Server stores
  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.  
Incorporate the GUID into the URN. This is where namespaces come into 
play again. You create a namespace associated with a unique URN, then 
maintain repositories that map the URNs to specific object 
descriptions and locations -- at the very least, this would give you 
an easy way to locate specific classes, and if you built in a schema 
protocol of some sort that give interface hooks to class definitions 
(something that I believe is currently evolving within SOAP anyway) 
then you could actually use one or more machines as proxies. 

  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.  
   
I have long felt that Java was not built for networks -- it was built 
as a stripped down version of C++, and it incorporated basic socket 
capabilities early on because the technology was there. XML is 
probably one of the first major network paradigms. 

Security worries me. We're dealing with a language that could 
simultaneously communicate over potentially tens of thousands of 
machines, and we better make sure that a compelling security story 
exists.
  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 .... 
That sounds to me like its actually a schema issue. The geneticist 
working with DNA will be dealing with a set of well established bio-
engineering schemas, and over time will likely evolve (sorry) a class 
of operations that can be handled on these schemas. Visually, this 
may be something as simple as dragging a Gene object into the work 
area. The gene schema has a specific URN, as well as a possible 
inherited URN, and transformations that can act on that Gene would be 
keyed to the URN. Thus, not only could the geneticist set a number of 
properties on the dragged object, but would expose a set of methods 
appropriate to that class of object (splice, createProtein, etc.)

I'm fading here, but I'd like to continue this discussion.

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




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



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