[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

XLink implemented in XSL

Subject: XLink implemented in XSL
From: Paul Prescod <paul@xxxxxxxxxxx>
Date: Fri, 14 May 1999 19:05:30 -0500
implementing xlink
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
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.