[
Lists Home |
Date Index |
Thread Index
]
Uche Ogbuji <uche.ogbuji@fourthought.com> wrote:
| Steve's message is one of the most clearly argued I've seen yet against
| XLink. It scores well, though he also weakens his case by exagerrating
| several matters.
As well as getting the semantics of 'embed' wrong, which vitiates his
examples in some specifics. So some specifics are not up to snuff, but
not the message, which is pretty clear. Yet revealingly enough the folks
on www-tag chose to ignore the message on the grounds that the examples
weren't "compelling", as if imagination couldn't figure how to make them
compelling, or that the correct interpretation of 'embed' could suffice
to rescue XLink! Okay, it's www-tag's job/nature to be conservative,
which usually winds up in defences of what's already there, but... Sheesh.
| So now he has explained clearly (for the first time, I think) why the HTML
| WG came up with HLink. XLink did not fit well with their test cases, so
| they specialized their own solution. The problem is that HLink is really
| no better than XLink. It solves just as limited a set of concerns.
Even more limited, I think. A few days back, I had posted examples of how
to model things like rollovers and dropdown menus (especially for multiway
jumps). I still haven't figured out how to use HLink for use cases such
as those. HLink, so far, is only about "explaining" the various ways in
which URI references appear in attributes in typical HTML documents. As a
definitional exercise, it's valuable in that some sort of regularization
of the taxonomy ought to occur at some point anyway, but I'm with you when
I read you to say that we were all expecting a bit more.
| If HLink had defined a generic system for attribute re-mapping that included
| a set of annotation for linking semantics, it would have actually achieved
| something meaningful, and thus would have justified the abandonment of XLink.
| I'm not crazy about arjun's offered syntax, but his approach is certainly
| srchitecturally sounder than that of HLink as far as I see it.
I've actually offered two ways to fix an immediate problem with this first
stab at a remapping mechanism. This @-prefix stuff is very ill-conceived,
and easily avoided.
http://lists.w3.org/Archives/Public/www-html/2002Sep/0051.html
There is another important structural problem with HLink. It is adopting
the same conceptual disaster as <OBJECT> - overgeneralization in a single
element type, a false economy. It leads to omnium gatherum attribute sets
with all sorts of interdependencies. (You'd think people would have
learned from the INPUT element in HTML!) It's all very fine to say that
if the effect attribute is embed and the actuate attribute is onLoad then
the onSuccess attribute means such-and-such, but without an *exhaustive*
analysis of the various combinations, the spec is deficient in untangling
a problem of its own making. This will result in either a reluctance to
implement because the bogotic combinations lack definition, or an interop
problem when the bogotic combinations are read as an invitation to um,
"embrace and extend".
Right now the major axis on which to split the HLink "superclass" into
"subclasses" would seem to be the 'effect' attribute.
|
