[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

XLink support in XSL

---

---

I've just had a quick read through the new XSL draft, and I'm puzzled as
to how it is going to support XLink.  (Maybe it isn't!)

The XLink "Show" axis supports the concept of links whose target should
either be embedded into the resource from which the link is made
("embed"), replace it ("replace"), or be displayed in a new context
("new").  

To support "embed", we need the ability to traverse an XLink and treat
the target (typically in another document) as a processible object.
This means a resounding "yes" to the editorial query in the XSL draft
"Should it be possible to select elements in other XML documents?".

The "replace" behaviour can be seen to correspond to clearing the
current window and displaying the target of the link in its place; "new"
can be thought of as an instruction to open a separate window.  Surely
we need a property that encapsulates this distinction so that browsers
know which thing to do?

Beyond this basic functionality, it would be exceptionally cool if the
XPointer syntax could be picked up from an attribute and correctly
interpreted by an XSL processor.

In general I don't quite understand XSL's link-related flow objects, and
would appreciate some gentle tuition.  We have an inline-link and a
display-link, each with a Destination property: no problem there.  But
then we come to link-end-locator which "represents a target for link".  

Do link-end-locators go inside inline-links and display-links?  If so,
isn't the Destination property redundant, since link-end-locator has
both HREF and ID[REF] properties?

And where is the merge-link-end-indicators property meant to live?

Best wishes,

Richard Light.

Richard Light
SGML/XML and Museum Information Consultancy
richard@xxxxxxxxxxxxxxxxx


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

---