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]
 > At 04:19 PM 9/13/2002 -0500, Bullard, Claude L (Len) wrote: > >I read this earlier and almost responded; it appears > >the WG is attemping a weak version of architectural > >forms. > > > >Is this another case of changing the names and adopting > >a piece of another technology (namespaces) that makes > >the result more complicated than the original and > >ends up being less powerful? > > No, see XHTML Modularization conformance definitions, > http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform . > These terms have been around for several years now (without argument from > the community). > > The point of the message is the linking examples, not an ideological > argument about application construction. I'm sorry, but as I read it, this last sentence is content-free. I don't know who was making "ideological argument about application construction". Certainly neither Arjun nor Len. Arjun's point is dead on, although I think he weakens it unnecessarily by sprinkling too liberally with trappings of his crusade against namespaces. 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. 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. I think we've all gained nothig if we just add another linking technology that covers a similar profile of problems as XLink, but with a somewhat different specialization. I got the earlier impression that HLink was generic, and thus somewhat akin to architectural forms. As I've said, I've been warming to this approach since the XHTML/XLink quarrel broke open. So imagine my surprise to read HLink and find that it is no more generic than XLink, and really nothing more than a set of selectors for presentation semantics related to linking. Why didn't you guys just define a new group of CSS selectors? That would have been far more sensible than the compulsive wheel reinvention that I see in HLink. HLink is a little bit XLink, a little bit RDF and a little bit CSS. As such, it adds up to a bug kludge to me. Micah Dubinko has been experimenting with alternate HLink syntaxes [1]. If AFs are truly beyond the pale for the HTML group, then I at least suggest that the working group switch to something that aligns with an existing technology. 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. And as we re-learn every day in the TAG battles, architecture matters. [1] http://dubinko.info/blog/2002_09_08_archive.html#81571209 -- 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/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html 
|
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
|
|||||||||
