RE: XSL file / "standalone" stylesheets - why not?

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

Received on Friday, 14 January 2000 13:11:24 UTC