This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XSL tree explanation


Hi Kevin,

> What I don't understand is how the stylesheet itself is considered
> the instruction tree(?) besides the fact that through numerous
> declarations and instructions does a well formed, and I guess you
> would say TREE structured document call itself an XSL file.

I'm not sure what you mean by 'instruction tree' here - I haven't seen
that term used before.

When the processor reads in the stylesheet, it constructs a tree from
it in just the same way as it does with a source XML document.  The
big difference is in how whitespace is treated.  You can control how
whitespace-only text nodes are treated in the source XML (using
xsl:strip-space and xsl:preserve-space) but you can't control it in
the stylesheet.  When the stylesheet is parsed, all the
whitespace-only text nodes aside from those in xsl:text are stripped.

(Note that this whitespace-only text node stripping is about the way
the file is used, not about the file itself.  If you access the
stylesheet using document('') then the tree will be built just like
any source node tree.)

> Also, I believe the xslt processor stores the source document in
> memory until the transformation takes place, but what about the
> RESULT tree? Is that the output file(ie the resulting HTML file) or
> is there an actual RESULT tree outputted/stored during the
> transformation?

When the source tree is processed by the stylesheet, the stylesheet
produces a result tree.  Theoretically, this result tree could be held
in memory, could be passed on as the source node tree to be used by
the next step in the transformation or whatever.  The result tree is
only serialised as the last step of the process, with xsl:output
controlling the details about how it's serialised.

It's *really* useful to think about constructing the result tree and
then serialising it rather than thinking about outputting to a file
because it stops you from falling into thinking procedurally about
what's going on.  You are not outputting tags, you are generating
elements that may later be output.

> The last one is probably why I'm missing the thinking behind
> <xsl:copy> and node-sets.

xsl:copy and xsl:copy-of copy a node (shallowly or deeply) from the
source node tree to the result node tree. Node sets are just
collections of (pointers to) nodes from the source node tree, that you
might apply templates to or iterate over or copy or whatever.

I hope that helps clear some of this up for you.  Do ask further
questions if you need to.

Cheer,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]