Re: Future XSLT expansion.

Subject: Re: Future XSLT expansion.
From: David Carlisle <davidc@xxxxxxxxx>
Date: Tue, 21 Mar 2000 10:28:34 GMT

> What happens inside the XSLT engine from your point of view?

I think one of the distinguishing features of xsl as opposed to some
other possible transformation languages is that it takes a purely tree
view of the process of transforming XMl documents.

Thus I think your desire to force all communication between the XSL
engine and external documents and extensions to go via a linearised
string representation of XML would entirely be against the natural
flavour of the language.

As I mentioned, I have no particular objection to the provision of a
pair of functions that parse a string as XML and conversely linearise an
XML tree, Extra functionality is always useful. I just don't see much
use for them directly myself. XSL already has enough problems as
typically an entire document tree has to be held in memory, I can't see
it will help much if you first have to pass the entire document as a
string, and then in addition construct the tree. Also that would give
XSL access to information it probably shouldn't have access to.
Such as whether " or ' were used around attribute values, the exact
white space appearing inside tags, etc. 

> How can 'server' return 'node-set' ? 'Server' returns text. String.
> XML file.

If I have SGML files (for which there exist sax compliant parsers)
or in principle files of comma separated fields, or anything else
the local setup can be arranged so that document() produces a suitable
node set on that file. Just as at the top level, the main input document
does not have to be a real linear XML file it might be for example an in
memory DOM resulting from an earlier transform. Saxon already has a
simple method of chaining together transformations. I assume (but
havent looked at the code) that it does _not_ write out the result tree
of one transformation as a string and the reparse the whole thing to
produce the input of the next transformation. The tree just goes
straight from being the `result tree' of one transformation to being the
`input tree' of the next. This to me is the essence of how XSL works.
Obviously from time to time these in memory trees need to be
externalised in XML concrete syntax (for example, but even without
extensions, other syntaxes are possible, eg html) but that is a parsing
and output process that in principle (and in practice in several
implementations) is distinct from the XSL stage which is about
transforming trees.

So I don't want to think in terms of linearising trees to strings in
order to communicate from the stylesheet to extensions, or to other
documents. If some protocols can only transport strings and not
structured objects then internally the tree may get linearised
transported and re-parsed, but that is a feature of that particular
protocol that I don't need or want to know about that. Either as an XSL
engine, or a person:-)

Your terminoligy is also confusing. You don't want to `typecast'
strings to node sets. By that I would (and did for several of your
messages) understand the oposite transformation to the current automatic
typecast of nodesets to strings, which would be to take a string
and convert to a node set which consisted of a text node with the value
being the string. You don't want a typecast, you want a new function
which is to make an XML parser available from within XSL.

David


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


Current Thread