Steve Muench Using the simple form gives up some features to achieve
simplicity of representation for people who want to continue
using their existing HTML editors to edit their "HTML
page with data plugged in" as they learn to exploit the
basics of XSLT.
The key limitation
is that you cannot use "top-level" XSLT-namespace
elements like:
xsl:import
xsl:include
xsl:strip-space
xsl:preserve-space
xsl:output
xsl:key
xsl:decimal-format
xsl:namespace-alias
xsl:attribute-set
xsl:param
in a "simple form" stylesheet. The feeling in the
XSL Working Group was, if someone began to
"discover" the need for these facilities, then they
were venturing beyond the "simple-case" stage, and
at that point we could assume they were mentally
"ready" to learn about an enclosing
<xsl:stylesheet> element and what <xsl:template>
is used for.
=== Some Background ===
The "simple form" of an XSLT stylesheet -- known in
the spec as "Literal Result Element as Stylesheet"
http://www.w3.org/TR/xslt#result-element-stylesheet -- was
conceived as a mechanism to allow someone familiar with HTML
to continue to use their familiar HTML editing tools to work
on stylesheets that only need a single, root template. The
feature was designed as a smooth-slope introduction
capability to be able to help people who knew HTML begin to
use XSLT without understanding the Spec cover to cover.
One very common case that the "simple form" caters
to, is the one where someone is formatting database query
results into an HTML page. Many Ecommerce apps are doing
this, making use of XML/XSLT, a stylesheet like:
<html xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xsl:version="1.0">
<body>
<table>
<!-- Imagine a "shopping cart" query -->
<xsl:for-each select="ROWSET/ROW">
<tr>
<td><xsl:value-of
select="ITEMNAME"/></td>
<td><xsl:value-of
select="PRICE"/></td>
<td><xsl:value-of
select="QUANTITY"/></td>
<td><xsl:value-of
select="PRICE*QUANTITY"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
This stylesheet can still edited using FrontPage,
DreamWeaver, etc. With the simple form, once you teach
HTML-savvy people that they:
(1) Add an XSLT namespace declaration and
xsl:version="1.0" to their <html> element, and | (2) Combine <xsl:for-each> for looping and
<xsl:value-of> to "plug in" dynamic data | (3) Use /a/b/c "directory-like" notation to refer
to elements in the source document (the way
I explain the basics of XPath to beginners) |
Then they can begin to get productive without having to
understand the XSLT spec cover to cover.
Steve Muench Adds:
From the spec, in the "DTD Fragment for XSL Stylesheets" you
can see what xsl-namespace attributes are allows on literal
results elements:
<!ENTITY % result-element-atts '
xsl:extension-element-prefixes CDATA #IMPLIED
xsl:exclude-result-prefixes CDATA #IMPLIED
xsl:use-attribute-sets %qnames; #IMPLIED
xsl:version NMTOKEN #IMPLIED
'>
So, using a "simple form" of a stylesheet like...
<html xmlns:xsl="http://www.w3.org/1999/XSL/Transform
xsl:version="1.0">
<body>
:
</body>
</html>
...in addition to the xsl:version="1.0" which is
mandatory, you can optionally add
xsl:extension-element-prefixes, xsl:exclude-result-prefixes,
and xsl:use-attribute-sets. So, using a simple form
stylesheet does *NOT* mean you give up extensibility or
ability to control namespaces on the output.
The only requirement to use these xsl: attributes is that
the xsl namespace be in scope on the element where you use
them. In my example above, if I'd include them on the
<html> element I'd be fine since that element
declares the "xsl" namespace.
Within the "simple" stylesheet you can use any XSLT
"action" which is valid to use inside a template.
Remember that the "simple form" is a shortcut for
defining a stylesheet with a single match="/"
template containing it as the template "body".
|