Re: XLink support in XSL

At 03:10 PM 12/18/98 +0000, Richard Light wrote (on the XSL list):
>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!)

This is an enormous issue, one that's come up several times on the
XLink/XPointer discussion list as well.  (Information on how to subscribe,
for those interested, is at the bottom of the page at
http://collie.fujitsu.com/hybrick/.)

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

Actually, it's worse than this.  A contingent on the XLink/XPointer list
wants XSL (or another style sheet-like mechanism) to actually determine
which traverses are possible, thereby handing the task of 'resolving' links
to the application.  This makes the 'yes' far more resounding - it also
requires XSL (or some other mechanism) to develop rules for handling style
sheets that operate between contexts.

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

Agreed, strongly.

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

Also, as discussed on the XLink/XPointer list, XSL transformations need to
be able to preserve linking information.  

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

Clarification on these issues would be helpful as well.

Simon St.Laurent
XML: A Primer / Cookies
Sharing Bandwidth 
Building XML Applications (February)
http://www.simonstl.com


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