Namespaces and XSLT simplified syntax

Steve Muench smuench at
Mon Jan 10 03:54:32 GMT 2000


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.

As you've encountered, the key limitation
is that you cannot use "top-level" XSLT-namespace
elements like:


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" --
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

<html xmlns:xsl=""
      <!-- Imagine a "shopping cart" query -->
      <xsl:for-each select="ROWSET/ROW">
          <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>

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, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
----- Original Message -----
From: "Dan Vint" <dvint at>
To: <xml-dev at>; <xsl-list at>
Sent: Sunday, January 09, 2000 1:13 PM
Subject: Namespaces and XSLT simplified syntax

| Here is yet another question on namespaces that I came up with after
looking at
| the XSLT specification and its simplified syntax. And let me go a little
| further back to HyTime.
| I understand (sort of) how an attribute on any'ol element can be pointed
to or
| mapped to an attribute in a different namespace by using a prefix to the
| attribute name as shown here:
| <html xsl:version="1.0"
|                 xmlns:xsl=""
|                 xmlns="">
| I also thought that architectural forms from HyTime allowed me to say this
| element of whatever name I specify should be treated like this other
| over here - I don't remember what the syntax is for it by I have sort of
| thought of namespaces as being related to this functionality.
| What I'm looking for is the syntax in XML/namespaces that would allow me
to say
| (in the above example)
| that my element <html> should be treated as <xsl:stylesheet> and thus
allow me
| to use content from the HTML content model for the element <html> and the
| content for the <xsl:stylesheet>. Of course I would use the namespace
| for those elements as well.
| Is there a method for aliasing two elements like this?
| There seems to be an indication that an xsl:stylesheet modeled style sheet
| should work the same as a stylesheet somehow being managed in a literal
| element (see the requirements for the version and other attributes in this
| case), but then the only example shown in the spec (and the only model
that I
| can think of) seems to fall squarely into the simplified syntax model
| then has the restrictions about only using instruction elements - am I
| mixing these two ideas up?
| Is the simplified syntax just a stricter set of requirements, but the more
| general form of using a literal result element as the document root and
| spreading xsl:xxxx top-level elements is allowed in the more general case?
| ..dan
| --------------------------------------------------------------------------
| Danny Vint                             
| Author: SGML at Work
mailto:dvint at
| Calian                                              Voice:804-975-3482
| mailto:d.vint at
| Charlottesville, VA Office      
|  XSL-List info and archive:

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list