[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] XLink implemented in XSL
Jonathan Borden wrote: > > Would something like this work? Is your goal to implement XLink or to implement some small subset of XLink applicable to a document type? The latter is definitely possible. I posit that the former is possible (gotta love Turing completeness) but incredibly painful to implement. I tried it and gave up. Here's a document type: <!ELEMENT link (locators)> <!ATTLIST link %I-am-a-linking-element;> <!ELEMENT locator EMPTY> <!ATTLIST link %I-am-a-locator-element;> <!ELEMENT otherstuff (otherstuff|link)*> How do I make a template rule that matches any element that is an anchor. Remember that anchor nodes are not explicitly labeled -- you just refer to them in a link and they "become" an anchor. Furthermore link, locator and otherstuff elements can all be anchors. I guess the important part of the problem could be expressed as the following query: "this rule matches nodes A such that there exists a node B such that B has an attribute called 'href' with a value that is an XPointer that can be dereferenced to return A." I tried to implement this specification but ran into two fairly fundamental limitations in XSL. #1. I can't figure out how to interpret a string from the document as a reference. I could re-implement XPointer or XSL queries in Python on top of the JVM on top of the Turing machine emulator that I haven't got around to implementing. Actually the XPointer in Python and Python on the JVM parts are already implemented but I haven't got around to the Turing machine and the JVM. Obviously it would be easier to use XSL's built-in extension mechanism to call Python but that would not be an implementation "in XSL." Now that XSL and XPointer are being combined I think that being able to convert a string to a query is a no-brainer. It is necessary anyhow. #2. XSL's support for building abstractions is extremely poor because the only data types that can be passed from a template to its caller are opaque result node sets and strings. But what you really want to return is nodes and node lists. I tried several tricks to get around this. I couldn't find one that would work. Basically it means that there is no way to store a query or query result set and use it as an input to another query. Insofar as XSL should behave as a superset of a query language I consider this a pretty big limitation unless I've got it wrong. It should also be possible to call a named template ("macro") from an expression. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 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
|