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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format