Re: Putting a set input-nodes together under XSL 1.0.

> > Are there technics which would allow me to introduce new input-nodes
> > into an existing set of  input-nodes without going through this
> > input-to-RTF-to-input transformation?
>
> No, XSLT takes a read only view of a source tree.
>
> On the other hand the only difference between a node set and a RTF (in
> most implementations, allegedly) is a flag that prevents you doing node
> set operations on the RTF, so the "input-to-RTF-to-input transformation"
> is most likely not a very costly operation. The fact that there was
> a distinction at all is widely seen as a mistake and the distinction is
> removed in the xslt 1.1 and xslt 2 drafts.

I'm not sure that's entirely true.  Node-sets usually contain nodes from
the input document.  RTFs, on the other hand, are created by the processor
on-the-fly as a separate "mini-document."  So, unless a processor is
incredibly clever, it will have to copy the nodes from the input node-set
into the RTF, and that's never going to be the cheapest operation.
However, I do agree with you that the actual operation of converting an RTF
to a node-set is likely to be very cheap.

It might be possible to create an RTF with the "new" nodes, then use the
nodeset extension function to get at those nodes, and create a new variable
that is the union of the original node-set and the nodes from the RTF that
you're interested in.  This would only work in certain situations, but,
depending on what you want to do with the "superset," it might work.
Things that wouldn't work would be operations that depend on document order
with the "superset," since the nodes would be from two documents, and that
order is processor-specific.

Ed, can you elaborate a bit more on what you're doing when you need to
create these amalgamated node-sets?

Dave


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