Re: Future XSLT expansion.
> 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format