Subject: Re: XLink support in XSL From: "Simon St.Laurent" <simonstl@xxxxxxxxxxxx> Date: Fri, 18 Dec 1998 12:37:54 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XLink support in XSL, Chris Maden | Thread | Re: XLink support in XSL, Chris Maden |
Dec16 - fo tables, Andy Dent | Date | Re: alternating tags in a list?, Keith Visco |
Month |