Re: XLink implemented in XSL

[James Clark <jjc@xxxxxxxxxx>]

Paul Prescod wrote:
> 
> 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.

> 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.

You can do it using docref(). (docref() handles URI references , that is
URI#fragment identifier, not just URIs.) docref(//link/locator/@href)
would find all the anchors. However, II think you would need some
built-in support in patterns and expressions to make supporting extended
links practical.  Even that wouldn't solve the problem of when an anchor
is not a single XSLT node (ie when it's an unmarked-up string); the only
way I can see to solve that is to have the anchor information in the
data model, eg having anchor nodes in the tree.

> 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. 

The current XSLT WD allows you to pass node-sets.

James



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