Lambda the Ultimate

XSLT is indeed the interesting part, but I recall it is not Turing complete. Perhaps I am wrong, as I don't really remember the details right now.

I used it to make my E-List archive sortable, without having to rely on anything from the web server provider (things like CGI etc.).

You can't see this yet, though I created it quite a long time ago (and that's why I don't remember all the details) since I had problems uploading to my site, and I lacked the time to transfer my site to another provider.

However, using IE5 (which was the browser with the required features, at least when I hacked my code), an XML file that describes the archive, plus an XSL style sheet, create an HTML page, that is automatically sorted when you press the column headings.

The things naturaly uses scripting, which in turn depend on the DOM etc.

As for progress, I've figured out how to pass parameters to named templates and do recursion. Now if I could just figure a way to return parameters from the template calls, I think I'd be satisfied that it qualifies as programming language.

Of course, I think the intent of the standards body was to avoid making it into a programming paradigm - preferring instead to keep it in the realm of pattern matching and transformation. IIRC, some of the early work on SGML transformations was based around Lisp derivatives and a decision was made to try to avoid that path.

XSLT is indeed the interesting part, but I recall it is not Turing complete. Perhaps I am wrong, as I don't really remember the details right now

As for progress, I've figured out how to pass parameters to named templates and do recursion. Now if I could just figure a way to return parameters from the template calls, I think I'd be satisfied that it qualifies as programming language.

Of course, I think the intent of the standards body was to avoid making it into a programming paradigm - preferring instead to keep it in the realm of pattern matching and transformation. IIRC, some of the early work on SGML transformations was based around Lisp derivatives and a decision was made to try to avoid that path.

One nice thing you can do using XSL is to perform client-side processing that otherwise might require server side processing, or heavier tools.

Even the server side tools are not quite ready. XPath and XSLT are both standards now, but XSL formatting is still not completed. Of course, if your just translating to text or html, the formatting aspect is not really necessary as that's geared more towards a client viewer or alternative document format generation (postscript, pdf, etc).

One real problem with XSL transformation on the server is speed. If you have a high volume of transactions, I don't think adding a layer as complex as XSL is going to help the performance much. The XSL engines are still fairly immature and the optimizations seem to be minimal. It will be some time before performance is up to snuff - right now your lucky if it behaves properly, much less fast.

In my experience, server side has been a joy. Solid reliable tools with predictable load/scaling characteristics are available. We're a Java shop and ended up using IBM's xml4j package along with the SAXON xsl engine. We've had zero problems in production with these two.

The kicker for us was the xml/xsl solution ended up being faster than our old JSP logic/presentation squished into one architecture. Really surprising. I think the key here was the extra caching we were able to bake in for managing the rendered xml/xsl pairs.

Our main presentation is html but we also do wap/wml/palm through the same engine and experience the same performance characteristics.

The problems for us involve finding skilled xsl people. That's been an experience.... We basically had to train our production group from the ground up.

gavin

In my experience, server side has been a joy. Solid reliable tools with predictable load/scaling characteristics are available. We're a Java shop and ended up using IBM's xml4j package along with the SAXON xsl engine. We've had zero problems in production with these two.

I did download the SAXON translator today and managed to get some work done. There's a particular extension that I was interested in (node-set($var)) that allows you to perform transformation on the output result tree that makes it particular nice for staging. SAXON also seems to be quite fast.

The problems for us involve finding skilled xsl people. That's been an experience.... We basically had to train our production group from the ground up.

I just related my experience with client side - and why this was useful for me: I don't have access to the webserver, I can only put simple html/xml files there.

Of course, from a programming language standpoint we are actually discussing to what extent is XML portable. On paper, there shouldn't be grave problems with using it either on the client or the server. The existance of implementations, is another issue.

By the way, DOM is also important, and naturally comes from ideas in OOP, and OO languages.

DOM is important but I wonder how important? There's already conflicting client/browser based DOM models. Plus the already existing (supposedly) implementation agnostic types of DOM like the w3c DOM and, another example, the new SVG DOM. Groves might (should?) alleviate the problems in dealing with disparate DOMs but, of course, add another layer of stuff/complexity.

I'm seeing a bunch of things recently that indicate XML Schemas are going to be the new model du jour. They'll do everything! Right.

Gavin

My speculation is that XSL is gonna be done as part of the programming staff, as opposed to the graphic designers.

We basically underestimated the type of work the production folks were going to do. If we did this again, it would be a different story of course. But, thankfully, some of the folks really took to the task and turned out to be pretty competent XSL coders. Then agin, XSL sometimes looks like Perl and that's not a good thing. Inscrutable to all.

Gavin

Suppose we have plenty of DTD that have container entities. For example <plants><flower>whatever</flower><flower>another</flower></plants>, where entities like <plants> that contain several other of a predfined set of entities will be called containers.

We want a "routine" that will process a file based on such a DTD (I don't care if it uses the DTD or not), and will receive to inputs: the container name (i.e, "plants") and the element name (i.e., "flower"). The resulting file will consists of one element chosen randomly. For example: <plants><flower>another</flower></plants>.

The "routine" shouldn't depend on the file structure, and will only use the inputs described.

Show me how to do this in XML/XSL.

We want a "routine" that will process a file based on such a DTD (I don't care if it uses the DTD or not), and will receive to inputs: the container name (i.e, "plants") and the element name (i.e., "flower"). The resulting file will consists of one element chosen randomly. For example: <plants><flower>another</flower></plants>.

In looking up random number generation in XSL, I ran across the following failed idea where the person was trying to use the generate-id() function to build a math:random() type function. The response to the message was that the generate-id would not work. And the final response, kind of indicates how the author was trying to do something similar to what you indicated in your message.

Which leaves me with the problem of generating a random number. If you want, I can show how an xsl file can read a number from an external xml file and use that number to condition the output for the plants file. This would assume that some external source is generating the random number and placing it into a file for use by the xsl process.

Short of that, I'd have to write a java function to return a random number that could be called from XSL. Unfortunately, the protocols for hooking into Java from XSL vary quite widely between implementations as the interface between the two is not defined by the standard.

Please do.

Which leaves me with the problem of generating a random number.

I had a feeling you kind of showed XSL to be Turing complete, awhile ago. If it is, it should be capable of expressing pseudo-randomness.

Here's the complete suite of DTD, XML and XSL file to print out the random flower. Note, I hard coded the number of flower entries in the xml file to 5. I assume there's a way to count the number of flowers in the file so that the range of the random number generated can increase (or decrease) with the actual number of flowers in the file. But for now, I think it gets close enuf for what you are asking for.

Don't know how well this will format, so I may have to experiment till I get it to look right on the weblogs.

Data Type Definition (plants.dtd)

<!ELEMENT plants (flower | tree)*>
<!ELEMENT flower (#PCDATA)>
<!ELEMENT tree (#PCDATA)>

XML Data File (plants.xml)

<?xml version="1.0"?>
<!DOCTYPE plants SYSTEM "plants.dtd">
<?xml-stylesheet type="text/xsl" href="polymorph.xsl"?>
<plants>
   <flower>Iris</flower>
   <flower>Magnolia</flower>
   <flower>Sunflower</flower>
   <flower>Petunia</flower>
   <flower>Daisy</flower>
</plants>

XSL to output random flower (plants.xsl)

<?xml version='1.0'?>
<xsl:stylesheet
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="1.0"
   xmlns:math="http://www.jclark.com/xt/java/java.lang.Math";>


   <xsl:output method="xml"/>


   <!-- Note: math:random() function is specific the the SAXON XSL translator -->


   <!-- get a random number in the range of the total flowers -->
   <xsl:param name="totalFlowers" select="5" />
   <xsl:param name="selectedFlower"
      select="round(math:random() * ($totalFlowers - 1)) + 1"/>


   <xsl:template match="/">
      <!-- output file uses the same DTD -->
      <xsl:text disable-output-escaping="yes">
         <![CDATA[<!DOCTYPE plants SYSTEM "plants.dtd">]]>
      </xsl:text>


      <!-- output the randomly selected flower -->
      <xsl:element name="plants">
         <xsl:copy-of select="//flower[$selectedFlower]"/>
      </xsl:element>
   </xsl:template>


</xsl:stylesheet>

Resulting XML Output

<?xml version="1.0" encoding="utf-8"?>
         <!DOCTYPE plants SYSTEM "plants.dtd">
<plants><flower>Petunia</flower></plants>

Perhaps I am missing something, but this still doesn't seem to satisfy my definition of standalone. It seems to me the "routine" is part of a file specifiying the structure of the result file. Perhaps this is the Right Thing to do. But, can it simply follow the structure of the input file?

Or maybe I am missing something? I am quite busy and don't have the time to check if what I wrote above really makes sense...

Perhaps I am missing something, but this still doesn't seem to satisfy my definition of standalone. It seems to me the "routine" is part of a file specifiying the structure of the result file. Perhaps this is the Right Thing to do. But, can it simply follow the structure of the input file?