Mike Brown 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:
<a/> 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.
| 
| XSL Frequently Asked Questions