[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: XLink support in XSL
Subject: Re: XLink support in XSL From: Chris Maden <crism@xxxxxxxxxxx> Date: Fri, 18 Dec 1998 16:50:52 -0500 (EST) |
[Simon St.Laurent] > 1) Is this really a task for XSL? Well, deciding how to present information is what I call styling. Whether the styling of links should be done in the same place as the styling of elements and text is certainly debatable; I think it should. > Are applications that aren't concerned with presentation in the > formatting/tranformation world going to need to cope with all of XSL > just to manage a few links? (Will this be a subsettable operation, > so that you don't need all of XSL, or are developers going to be > stuck with the whole damn thing?) I think they will, because you don't know what's a link until you've got the formatted document. Certainly things marked with XLink are links; but what about IDREF pointers? What if my stylesheet finds all occurrences of certain words and turns them into links? An application that does something interesting with links should probably know about those. > How does it relate to formatting objects? The formatting objects are a way of presenting information to a user (be it human or robotic). The thing-you-click is presentational; it represents an informational relationship, just like the thing-that-is- bold represents some kind of information about that element. > 2) Does XSL have any way to cope with styling across multiple > contexts and documents? Simple example: I load document A, which has > a link (A, B, C). A's style sheet says to create traversal paths > A->B, B->A, A->C, C->A. I go to B, and its stylesheet interprets > the link as B->A, B->C. I go to C, and its owners don't want anyone > annotating, so they've specified that no links from outside the > document should be accepted. User X has their own style sheet that > they slap on top of all this with yet a different interpetation. > Making multidirectional links robust enough for the Web is going to > require some heavy rule-making. 'Persistence' - necessary for > multidirectional linking and hub groups - brings up some very odd > issues that need to be addressed. This is a good question, and it hasn't been thoroughly discussed yet. Everything has some sort of default rule; for elements, you end up with the textual content inline. For link ends, I'd suggest that the default be blue underlined or outlined clickable objects in GUI browsers, and numbered selectable bold text in Lynx. In other words, that they be hot. The stylesheets in effect might specifically handle certain link roles, while others would receive the default behavior, or have only the color changed. An author's stylesheet might expressly turn off linking from a document, but the user's stylesheet or the browser's built-in one[*] might well override that. There is an interesting question in "the stylesheets in effect": which are those? Does the stylesheet of the document in which the link occurs take effect? The stylesheet of the document in which the link end is found? Do they cascade together? It's a tough question. You have the potential for clashing roles, since that space (I can't call it a namespace any more...) is completely ungoverned. But I firmly believe that no subject can't be analyzed to death or boredom. (-: > 3) Is CSS going to provide similar support? (I realize that's not > completely relevant to this list.) CSS already has some simple support in its :link pseudo-element and kin. It doesn't have explicit XLink support in accessing qualities of the link or link-end, but it can match followed, unfollowed, or active links. That's all from me! I'm leaving soon for a week, and I can't afford to spend any more time on this before I go away. So don't say anything interesting please! -Chris [*] Which, remember, need not be actually instantiated as an XSL or CSS document. -- <!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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XLink support in XSL, Simon St.Laurent | Thread | RE: Does the XSL processors within , Markor, John (Non-HP |
using DOM, Jeff Beck | Date | RE: Does the XSL processors within , Markor, John (Non-HP |
Month |