[
Lists Home |
Date Index |
Thread Index
]
Left this response till I had enough of a moment to give it some thought...
> 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.
All put quite well, and I agree. I also agree that individual elements should
be subject to control, which is why I like the idea of reusing CSS, which has
sophisticated mechanisms for all that.
> > 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?
One good example is the common download page meme (OK, this one is more often
done with server-side scripting than with Javascript). I think that when you,
say, download something at SourceForge and it puts you through the rigamarole
of finding mirrors, that this is conceptually an extended link. It is all the
same link, but possible with different end-points. Examples where Javascript
and all that is used are rollover menus where you can use mouse manipulation
to manipulate a menu item im place. Examples of out of band links (not that I
think these are fodder for the HTML WG) are all the annotation systems out
there: crit and friends.
> 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,
I think this can be a strong hint, but I think there are also forms that are
conceptually extended links but do not have all the end-points expressed int
eh 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.
The processing pipe rears its ugly head again. I think DSDL is hot on the
trail of this. A linking interpretation layer would seem to be a natural DSDL
plug-in.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.
html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html
|
