[
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
|
