[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: XLink and XSL...
Subject: Re: XLink and XSL... From: Guy_Murphy@xxxxxxxxxx Date: Thu, 25 Feb 1999 11:20:25 +0000 |
Hi Chris. I may well have gaps in the area of linking (if so be kind :), I certainly haven't considered all the permutations XLink brings to document presentation, or we may simply be missing each others intent here slightly... Firstly, there are definately mechanisms that need to be worked through to allow user agents to manage and work with complex linking, but that isn't really what I'm after here (although I'm sure I will be as my grasp of the area broadens). What I'm concerned with is mechanisms that allow *me* to work with extended links from XSL as to produce in dHTML my interpretation of the link relationship. You say that linking should be layered above the parser, and I'm not quite sure what you mean by this. As I see things currently XLink is just data that's linked to a document as a resource, all I want is to be able to work with that data from XSL. On the subjest of preserving extended links across transclusion, I'm not sure that this is any different from documents with dynamic inclusion compared to wholy specified documents, at the end of the day unless the transformative process can write result to both the result document and another document maintaining the extended links, this linkage straight out dies and forces specify links in the result document if you want them preserved. Hmmm, maybe rather than suggesting that XSL should be the active process in aggregation I should shift to your terminology and suggest that XSL should be the active process of transclusion. If XSL supports multiple inputs and multiple outputs then all XLink becomes is a common way to describe links, as the author has the means it's up to them how they choose to manage and present the XLink description. Lastly you note that an XPointer doesn't point to the styled result... it shouldn't automaticaly do so. The result is a *different* document. There is also the concept of document ownership. You may mark-up an XML document and if I produce an XSL stylesheet for it the result is an interpretation of that document... *my* interpretation, and it should surely be my responsibility to carry over any links necessary or deemed appropriate. It may be a difference in approaches but I wouldn't term two instantiations of an input element instead two interpratations of that element that may indeed be a more complex, simpler construct that might differ from each other conceptualy. Surely it's up to the XSL author to establish how traversing a link pertains to these result elements. In short the input document and the result document are two separate entities. How closely they relate to one another is down to the author of the XSL, and relationships between the two should be *facilitated* by XLink/XPointer, not *stipulated*. If XSL does become the active process of transclusion then the result may have relationships with more than one preexisting documents. If XSL isn't to be the active process of transclusion what is (surely we're not going to rely on the user agent)? Cheers Guy. xsl-list@xxxxxxxxxxxxxxxx on 02/24/99 08:00:09 PM To: xsl-list@xxxxxxxxxxxxxxxx cc: (bcc: Guy Murphy/UK/MAID) Subject: Re: XLink and XSL... [Guy Murphy] > Is anybody looking at how XLink might be integrated with XSL? That would be me. Others, too. > Given that the navigation metaphor is often a major part of a Web > site UI, and in the future XLink (or XLink-like mark-up) as a > resource external from an XML document might we the method of choice > for a lot of designers, I think this might be of great import to > XSL. > > I haven't looked at XLink in any great detail (intend to try and > correct that this week-end), but are we going to have to look at a > mechanism for XSL to combine or take two input trees? Or do we have > to wait on XML parser support for XLink directly. One important requirement for XSL is a means of addressing link ends. It's a hard problem, though, because a link end doesn't necessarily nest properly in the element structure. > If it's an XSL concern then a mechanism can probably be produced > that will have application beyond XLink. If it's an XML parser > concern then we might end up with a highly specific solution. Linking should be at a layer above the parser. [Simon St. Laurent] > 2) Using XSL to present links (display issues) and preserve link > information across a transformation The first problem, styling, is very hard. A paper discussing some of the problems can be found at <URL:http://www.oreilly.com/people/staff/crism/xsl/linkreq.html>. Preserving link information across a transclusion isn't hard if the links are in the document. But keeping extended linkends that are stored in another document is tough, because the link document won't be pointing at the result of the transformation, most likely, and inlining the previously out-of-line links could be a nasty bit of work given the fact that the link ends (as previously mentioned) may not align with element boundaries. > 3) Using XSL to determine the traversable paths in a link > relationship, which are left undefined in XLink extended links. > (Extended links are just a set of resources, not something you can > traverse like a simple XLink or an HTML link.) > > All of these are important. #3 is a hassle, since it seems to leave > XLink dependent (in my view) on a style sheet system that many > applications will find to be useless overhead (i.e., those that > don't actually display the links or perform any other > transfomations). Of course, I've been shouted down on that point a > number of times on xlxp-dev. #3, to my mind, is necessary. Without it, there's no flexibility. There must be the ability to style a link where XLink wasn't used, for instance in ID/IDREF situations. Since that's a requirement for XSL anyway, it makes sense to use that same capbility for XLink links rather than duplicating the functionality. The real problem is identifying the link ends from within the stylesheet. With HTML and CSS, I'll color different kinds of links differently; I should be able to do at least that in XSL, plus generating text or transforming the link in some way. Another problem that we've become aware of since I wrote the paper is identifying the canonical location of an element. An XPointer locates an element, not its styled result. So if an element is instantiated twice in a styled document (as a simple example, a chapter title that appears both at the start of the chapter and in a cross-reference), where in a styled document does traversing a link take you? In some cases, a human can tell easily, but in the general case, how can the problem be solved? I need to update the paper, I think. -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XLink and XSL..., Vun Kannon, David | Thread | problem!!, Jayadeva Babu Gali |
Re: problem!!, Juliane Harbarth | Date | RE: Complex XSL Application (I thin, Guy_Murphy |
Month |