Namespaces and XSLT simplified syntax

Dan Vint dvint at
Mon Jan 10 13:29:31 GMT 2000

>From the answers I've seen it appears the simplified method has its
restrictions to 
make it simple, so with that can I infer that it is also possible to have a
 setup similar to the simplified model that has the full capability of a
standalone stylesheet. 

The reason why I ask, is when you look at extension elements,
processing, exclude-result-prefixes the spec will list xsl:stylesheet and
literal result 
elements with the appropriate attributes prefixed with xsl: .

This seems to imply a full featured version of a stylesheet being
intermixed in the 
source document, but not embedded where the xsl:stylesheet element is used.

Now I don't know what the value of such a thing would be (one less file to
maybe) I'm just trying to understand all the "rules" in the specification.


At 07:39 PM 1/9/00 -0800, Steve Muench wrote:
>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:
>  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"
> --
>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
> > xsl:version="1.0"> > > > > > 
> > > > > 
> > > >
>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 element, and > (2) Combine for looping
and > 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" >To: ; >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: >| >|
>| 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 >element >| 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 should be treated as and thus
>allow me >| to use content from the HTML content model for the element and
the >| content for the . Of course I would use the namespace >prefix >| 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 >result >| 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 >which >| then has the
restrictions about only using instruction elements - am I >just >| 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 > 

Danny Vint                             
Author: SGML at Work 
                                                       mailto:dvint at
Calian                                              Voice:804-975-3482
mailto:d.vint at
Charlottesville, VA Office                    

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