XLink implemented in XSL

[Paul Prescod <paul@xxxxxxxxxxx>]

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