I'm inclined to agree that this is not the most useful of facilities: very few people use embedded stylesheets, very few use simplified stylesheets, and the number who use both at once must be vanishingly small. However, I think it's well specified, and I think there was a consensus that XSLT 1.0 allowed it, so I'm not convinced there's a case for removing it.

I can see potential use cases in a language that embeds XSLT, for example a future pipeline processing language might have an instruction <pp:transform> whose content is a stylesheet module, and I don't think there's any logical reason to say that this can't be any stylesheet module including a simplified one.

In fact I think there's a good principle somewhere that any element that makes sense as the outermost element of a document also makes sense embedded at a deeper level: it's a good principle because it allows composability of languages.

Any XML element is the root of a simplified stylesheet module if it satisfies two conditions: the XSLT namespace must be in scope, and it must have an xsl:version attribute.

I don't understand the difficulty with the context node. The context node is a run-time concept and refers to a node in the source document, not in the stylesheet.

Perhaps you were thinking of embedded stylesheets in terms of embedding within the source document (the document being transformed). I don't think that's the important use case: it's embedding within other languages, things like Ant, that matters.

Michael Kay

Part 3.11 begins with a bullet list of two forms of embedding that are possible,
neither of which is a simplified stylesheet (no xsl:stylesheet element) within
an XML document other than as the document element. This is not precisely aligned with the definition of embedded stylesheet module given at the beginning of Chapter 3. Since the verbiage makes clear that embedded simplified exists, we want to know how one would determine the boundaries of the stylesheet module(s) in an XML document, but not the document element, in the absence of an xsl:stylesheet element.

3.10.1 clearly says that xsl:import and xsl:include can pull in an embedded simplified stylesheet module. If a standalone standard stylesheet has no template for match="/" and has an xsl:include referencing the file below (the whole file, without a fragment identifier), what do we expect?

<?xml version="1.0"?>
<outer xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <foo>
    <bar1 xsl:version="2.0">
      <xsl:value-of select="concat('bar1','was','called')"/>
    </bar1>
    <bar2>bar2 content</bar2>
  </foo>
  <bar3 xsl:version="2.0">
    <xsl:value-of select="concat('bar3','was','called')"/>
  </bar3>
</outer>

It looks like there would be two match="/" templates resulting from the include.
Next question: same as above, but xsl:version="2.0" is also present on <outer>.
Next question: if the xsl:include supports fragment identifiers, what if <foo>
is indicated as the start of the fragment?

>Part 3.11 begins with a bullet list of two forms of embedding that are
>possible, neither of which is a simplified stylesheet.

Fair comment. (This is very old text - I've no idea what the reference to embedding in a non-XML resource is getting at, but it's straight from 1.0)

>we want to know how one would determine the boundaries of the
stylesheet module(s) in an XML document

I think it's up to the user invoking a transformation to identify the stylesheet they want to use (by identifying the element at the root of the tree containing the stylesheet module), and it's then up to the processor to check that this tree represents a valid stylesheet module. It's valid if (as a minimum) the element identified is xsl:stylesheet or xsl:transform or is something not in the XSLT namespace but having an xsl:version attribute.

>If a standalone standard stylesheet has no
template for match="/" and has an xsl:include referencing the file below (the
whole file, without a fragment identifier), what do we expect?

An error. The outermost element of this document has no xsl:version attribute, therefore it is not a stylesheet.

>Next question: same as above, but xsl:version="2.0"

In this case it is a valid stylesheet, it is transformed into a "standard" stylesheet using the transformation in 3.7, and all is well.

>Next question: if the xsl:include supports fragment identifiers, what if <foo>
is indicated as the start of the fragment?

If the result of the URI dereferencing is an element rather than a document, then we try to apply the transformation in 3.7 to that element. If the element has no xsl:version attribute then this transformation will fail to produce a valid (standard) stylesheet module, so it's an error.

Michael Kay

I was asked to propose clarifying text. Here are my suggestions.

(1) In the note at the start of section 3, replace the sentence "Except in the case of a simplified stylesheet module, this will be an xsl:stylesheet or xsl:transform element. " by "In the case of a standard stylesheet module, this will be an xsl:stylesheet or xsl:transform element. In the case of a simplified stylesheet module, it can be any element (not in the XSLT namespace) that has an xsl:version attribute."

(2) In the sentence:

Both forms of stylesheet module (standard and simplified) can exist either as an entire XML document, or embedded as part of another XML document, typically a source document that is to be processed using the stylesheet.

after "typically" add "but not necessarily".

(5) In 3.7, mention that because a simplified stylesheet cannot contain a named template, it must always be invoked by supplying an initial context node that is matched against the implicit match="/" template rule; and that in practice it only makes sense for the initial context node to be a document node (because otherwise the transformation will be performed entirely by built-in rules).

(6) Change the introduction to 3.11 (Embedded stylesheet modules) as follows:

An embedded stylesheet module is a stylesheet module whose containing element is not the outermost element of the containing XML document. Both [standard stylesheet modules] and [simplified stylesheet modules] may be embedded in this way.

Two situations where embedded stylesheets may be useful are:

* The stylesheet may be embedded in the source document to be transformed

* The stylesheet may be embedded in an XML document that describes a sequence of processing of which the XSLT transformation forms just one part.

The xsl:stylesheet element may have an <code>id</code> attribute to facilitate reference to the stylesheet module within the containing document. 

... then the Note and the rest of the section follows.

In the final Note, after "Support for the xml-stylesheet processing instruction is not required for conformance with this Recommendation." add "Implementations are not constrained in the mechanisms they use to identify a stylesheet when a transformation is initiated: see 2.3 Initiating a Transformation.

(1) is an excellent clarification. It is now clear that if you want to have an embedded simplified, you cannot have an XSLT instruction element as the outermost element. A further implication is that there exist XML documents that cannot qualify for any of the four kinds of stylesheet module; more on that below.

(2) restricts embedding to be within an XML document, as does the definition of embedded two paragraphs below it in the CR. This is a change from XSLT 1.0, which allowed embedding in a non-XML resource. Not that *I* would complain about that. More on this topic at (6) below.

(5) is a good addition. I think you should also state initial mode and stylesheet params can't be used (or have no effect), so that we know that the WG discussed it and it's not just an error of omission.

(6) refers to "the containing XML document" as opposed to "the containing document" which I take as a signal that you don't want to allow embedding in a non-XML resource. The introduction to the two new bullet items signals to me that you don't want to provide an exhaustive list of all the ways that embedding can occur. Perhaps you want to say something to indicate other possibilities exist?

When considering embedded stylesheets, there are two situations where you need a method of locating the stylesheet module:
1. How it is identified at launch time as the "principle stylesheet module" (term used in 2.3, defined in 1.1)
2. How it is identified for import/include (as required in 3.10.1)
Both of these are implementation-defined, and I don't see anything to indicate that the mechanisms for methods 1 and 2 above must have anything in common. Much of my conversation with Scott Boag was about whether it is adequate to provide the whole containing document and leave the implementation to detect the start of the stylesheet module, or whether the intent was that some precise pointer must be provided, analogous to the launch option of identifying an initial context node for the transformation input. Michael Kay argues for the precise pointer when he says: "I think it's up to the user invoking a transformation to identify the stylesheet they want to use (by identifying the element at the root of the tree containing the stylesheet module)..." (from comment #3). This issue is especially interesting for the case where the input has an embedded stylesheet for transforming itself but does not have the xml-stylesheet PI.

If you launch a transformation with an XML document and indicate that it is to transform itself, and the outermost element is not xsl:stylesheet or xsl:transform, what rules apply? Clearly, you don't want built-in rules to take effect until some form of stylesheet module has been identified. More pointedly, at some point the processor could recognize that the document is not qualified to be any of the four kinds of stylesheet module; what error codes are needed? I don't think that XTSE0150 and XTSE0165 cover all possible situations.

Following the decision of the working group today:

Referring to comment #4,

change (1) has been applied.

change (2) has been applied. The rationale for dropping any mention of embedding in a non-XML resource is not that it's impossible or disapproved of, but that it's out of scope. If someone wants to define a way of embedding XSLT in Java, that's up to them.

(3) and (4) don't exist

(5) At the end of 3.7 I've added:
<phrase diff="add" at="ZA">Simplified stylesheets therefore cannot use 
<termref def="dt-global-variable">global variables</termref>,
<termref def="dt-stylesheet-parameter">stylesheet parameters</termref>, 
<termref def="dt-stylesheet-functions">stylesheet functions</termref>, 
<termref def="dt-key">keys</termref>, 
<termref def="dt-attribute-set">attribute-sets</termref>, or
<termref def="dt-output-definitions">output definitions</termref>.  
In turn this means that the only useful way to initiate a transformation is to supply a document node as the
<termref def="dt-initial-context-node">initial context node</termref>, to be matched by the
implicit <code>match="/"</code> template rule using the <termref def="dt-default-mode"/>. 


(6) Change applied as proposed. Yes, the aim is to be illustrative rather that exhaustive.

We don't want to prescribe (or even describe) the many ways that a processor might choose to locate an embedded stylesheet module, other than directly by using its id. In some cases it might be implicit in the rules of another language, for example there might be an <ant:transformation> element that has the <xsl:stylesheet> element as a child. Or someone designing a content management system might want to define an XML document format containing multiple <xsl:stylesheet> elements, each with attributes (in some namespace) suggesting the circumstances in which it is to be used. All such mechanisms are essentially ways of identifying the root node of the stylesheet to be used: we only need to say that the node must be identified, not how.

I was directed by the WG to mark this as fixed after reporting the changes applied, which I will now do. Feel free, however, to comment further.

Michael Kay
for the XSL WG

The WG reviewed the changes on 10 May 2006 and approved them. The issue is therefore now closed.