On the XSL list, someone said: > There is no such thing as a standalone XSL page...
Not really wrong, but not 100 percent true either, especially with the advent of the document() function.
An XSLT engine only needs one source node to process: a root node. This root node is not something that is specified in an XML document (its not the same as the root/document element).
(Kay Michael commented Not strictly true. XPath section 5: "XPath operates on an XML document as a tree". The source tree always represents a well-formed XML document, so it must include an element as a child of the root. )
(To which David Carlisle responded: not strictly true: section 3.1 says... When the source tree is created by parsing a well-formed XML document, the root node of the source tree will automatically satisfy the normal restrictions of having no text node children and exactly one element child. When the source tree is created in some other way, for example by using the DOM, the usual restrictions are relaxed for the source tree as for the result tree.)
If there is only a root node, there is no reason to assume that there was an XML document or other data source from which the source tree was constructed, and in my opinion, it follows that there is no reason for an XSLT processor such as XT to require such a source document as one of its command-line arguments -- a source tree consisting of only a root node can be the default, if no other data source is provided. I mentioned this either on the XSL list or to James Clark directly (I don't remember which) but my comment was not acknowledged.
I realize that the spec only deals with tree transformations and this is a peripheral implementation issue, but the spec does make recommendations for how a processor should handle output... so why not also make a recommendation like this for how it should handle input?
Steve Muench adds:
The thing being transformed would be whatever datasources you bring in through functions like document() or extension functions that return nodesets.
For example, consider the dummy source XML file of:
and the stylesheet of:
<html xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xsl:version="1.0"> <!-- The airport code you want to search for --> <xsl:variable name="code">VENI</xsl:variable> <!-- | Get some dynamic XML Data over the web from | an XSQL Pages-based XML Data Service running | on an Oracle Demo Machine on the internet + --> <xsl:variable name="airportServiceURL" select="concat( 'http://ws5.olab.com/xsql/demo/airport.xsql?airport=', $code)"/> <xsl:variable name="airports" select="document($airportServiceURL)"/> <body> I found the following airports matching '<xsl:value-of select="$code"/>':<br/> <table> <xsl:for-each select="$airports//Airport"> <tr><td><xsl:value-of select="Code"/></td> <td><xsl:value-of select="Description"/></td> </tr> </xsl:for-each> </table> </body> </html> If you go process this stylesheet, the result will be: <html> <body> I found the following airports matching 'VENI':<br> <table> <tr> <td>PVE</td> <td>El Porvenir, Panama Republic</td> </tr> <tr> <td>TSF</td> <td>Venice, Italy-Treviso</td> </tr> <tr> <td>VCE</td> <td>Venice, Italy-Marco Polo</td> </tr> <tr> <td>VNC</td> <td>Venice, Florida, Usa</td> </tr> <tr> <td>WPR</td> <td>Porvenir, Chile</td> </tr> </table> </body> </html>
This airport data is coming over the web from an Oracle database running out on the Internet that can serve information about airport codes
Later adding in response to questions:
> Okay, I understand about using document() (at least with one > argument, as somebody -- Mike Kay? -- just said :). But then > doesn't that document constitute a source tree, even if it > consists of just a single root element?
Yes it does, it is *a* source tree, but it is not the primary source tree that the XSLT processor will initially act upon.
My argument was that a source tree could consist of just one node, the root node, which is one level above the root element found in a well-formed XML document. Mike Kay just dug up an interesting quote from XPath section 5: "XPath operates on an XML document as a tree", with the implication being that a well-formed XML document must have one element.
I did some more looking and found this in XSLT section 3.1:
"When the source tree is created by parsing a well-formed XML document, the root node of the source tree will automatically satisfy the normal restrictions of having no text node children and exactly one element child. When the source tree is created in some other way, for example by using the DOM, the usual restrictions are relaxed for the source tree as for the result tree."
So, in XSLT land, a source tree does not have to be derived from a well-formed XML document, and in such a situation, it could consist of just a root node. But when it is being created from a well-formed XML document, then it will/must have at least one element.
My point was that there should be a recommendation for whether an XSLT processor should require a primary source tree as input. Is there a justification for requiring *only* a stylesheet document or stylesheet tree as input? I still say "yes", as long as a single root node can be the default. It can be the default, IMO, because a source tree can consist of only a root node, which is possible because there are no restrictions on what it is derived from (non-well-formed XML, DOM, etc).
> could you describe a situation in which it makes sense to have > XSLT do this? It seems like swatting flies with a hammer. Do > you have some process hooked up at the back end which must take > all its input from an XSLT processor?
I am developing an application that feeds to XT a lengthy stylesheet and a very short source document. In the source document I have 4 or more URIs pointing to the locations of various data sources that the stylesheet makes use of via the document() function. Most of these URIs are stable enough that they could be hard-coded in the stylesheet, but in my particular environment it is better that they be in a separate file.
The other data sources referenced by the URIs are right now XML files that convey information about the content, structure, and visual aspects of a web site. They are being generated just prior to the XSLT processing, and are set up such that one of the files could be modified or swapped out without necessarily requiring changes to the data in the others. Site structures can be pregenerated without knowing design or content information, for example. In the near future, we'll no longer have these in files; they'll be either in DOM objects or in XML streams that are piped directly to XT's guts.
Anyway, if I hard-coded the URIs in the stylesheet, XT would still require me to use some other XML document as the primary source tree, even though that particular source tree would be ignored.
> using the document() function to provide your sole source of > "input" doesn't radically change the notion of having a source > tree, does it?
No, it doesn't change the notion of having "a" (secondary) source tree. It changes the notion of having a primary source tree to be required as input. I'm not trying to change the definition of source trees. I'm just trying to clarify whether the spec should recommend that a processor should have a default for "the" source tree if none was provided.
Inline (embedded) XSL within XML document
The canonical format for such a thing is as follows:
<?xml version="1.0"?> <?xml-stylesheet href="#style" type="text/xsl"?> <document> ... ... ... <xsl:stylesheet id="style" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > ... xsl elements ... <xsl:template match="xsl:stylesheet"/> </xsl:stylesheet> ... ... </document>
If you notice, the <stylesheet> element is embedded inside the document element. The stylesheet element has an "id" attribute; This "id" attribute is in turn used in the processing instruction "xml-stylesheet".
Additionally, I have defined a template for the "xsl:stylesheet" element, so that I can exclude it from processing by the XSLT engine.