OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] [Fwd: The problems with Xlink for integration langu ages]

[ Lists Home | Date Index | Thread Index ]

> 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






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS