[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]
Uche Ogbuji <uche.ogbuji@f...> 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.
|
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
|