[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XLink support in XSL
[Simon St.Laurent] > 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. I'm one of them. A link expresses a relationship. Here's an analogy: An element has a name, its type: it is a string with no inherent meaning to the application. It has parent and possibly sibling and child relationships. *That's it.* It isn't bold, it isn't purple, it isn't chocolate. A stylesheet takes elements matching a pattern, simplistically those whose type matches an arbitrary string, and formats them as e.g. a paragraph with vanilla borders and loud funk music. You all know this: it's what stylesheets do. But watch this: A link has a name, its role: it is a string with no inherent meaning to the application. It has linkends, each possibly with their own role. *That's it.* It isn't clickable, it isn't autoload, it isn't blue, it isn't underlined. A stylesheet takes linkends matching a pattern, simplistically those whose role matches an arbitrary string, and formats them as e.g. an inline string with a clickable icon. Why should this be any different? When you've identified that a particular point in a document is a link-end (which XSL can't yet do, but will), decide based on the roles and built-in XLink hint attributes whether, per *your* application conventions, it should be automatic (in which case just go and get the content, no linking involved for the user) or if it should be an activatable link, or not "hot" at all. -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
|
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
|