Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [Fwd: The problems with Xlink for integration langu ages]
![Re: [Fwd: The problems with Xlink for integration langu ages]](/images/get_stylus.gif) Hi Uche, > Behavioral aspects of linking should certainly have a mechanism for > override in the instance. I believe this is the job for CSS. I am > also not convinced that there should be no mechanism for expressing > linking semantics in the instance document. Yes; I've been being naive. In many ways, linking is a lot like presentation in terms of how it can be applied at both a global level and a local level. At a global level there can be a general linking semantic and behaviour for a particular element such as "all <a> elements point to a page that should be shown on user request". At a local level there can be a requirement to override this general semantic or behaviour, such as "this particular <a> element is pointing to the home page". Like presentation, at least for a presentation-oriented language like XHTML, those semantics/behaviours at the *global* level are *built-in* to the language. You really don't want to have to specify, in every XHTML document (or referenced CSS stylesheet), that a <p> element is a block element. Likewise, you really don't want to have to specify, in every XHTML document (or referenced whatever-you-use-to-specify-linking), that an <a> element is a link that is activated by the user clicking on it. This is really what I was trying to get at by the "put it in the schema" suggestion. If you have something that is built-in to a language as a default, then it doesn't make sense to repeat that in every single instance document. I believe that the proper place for these defaults is in the schema (I'm using 'schema' in a very general sense meaning "the place where you describe and specify the structure and semantics of your markup language"). XLink does this, for example, by having fixed and defaulted attributes specified in the DTD. It appeared to me that, on the contrary, HLink was advocating repeating the same link specification in every instance document. But you're absolutely right that you need to have a local mechanism as well. Importantly, though, it should be at the level of individual elements. HLink, from what I can see, defines things at the level of all-elements-of-the-same-name. It seems to me that something along the lines of CSS selectors or XSLT patterns would work well here, enabling you to target elements depending on their name, their class or individual elements by their ID. XLink manages this, of course, by allowing you to override the default XLink attributes on particular element instances. > In particular, I do not think extended links should be ditched, and > I think that extended links would require some semantic notation in > the instance. > > People always say they don't "get" extended links and then go right > on to reinvent them. Right now, HTML authors build extended links > using rickety prefabs of simple links and Javascripting. Even the > HTML WG has sorta reinvented them in the new navigation links > thingie (and possibly in other places). I think that almost any > declarative approach to extended links would be easier for Web > designers than figuring out what combination of iffy HTML and > specialized scripting can be made to somewhat work in the variety of > browsers. Just because it will help me visualise this, can you describe an example of where what should be an extended link is used in an HTML page? My only, random, thoughts are that (a) perhaps you can implicitly understand that a link is an extended link by seeing that the simple links are all attributes/children of the same element, (b) if you're right, you do need something more than CSS, and HLink isn't there yet, (c) if we have to have a new mechanism here that works in a similar way to CSS isn't it time we started unifying the way individual documents can point to related resources so that applications don't have to know about 15 different ways to get information about a document, and (d) if we could rely on a transformation layer and XLink comprehension we wouldn't have to make up a new language for describing links. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ 
|
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
|
|||||||||
