[
Lists Home |
Date Index |
Thread Index
]
Christopher R. Maden wrote:
> Pretty much... XLink started out trying to grandfather HTML markup.
> There were really three options with respect to that requirement:
>
> 1) Automatically recognize "href" ...
>
> 1a) Automatically recognize "href" as the target attribute only within
> documents that are determined to be HTML. ...
>
> 2) Introduce a general attribute renaming scheme à la HyTime.
> This was what was in the early drafts of XLink. It had the drawbacks
> of being ugly and of being tainted by association with HyTime.
>
> 3) Ignore the requirement.
> This has the obvious drawback of not meeting the requirement!
>
> The XLink WG (and the XML WG before it) made a good-faith effort at
> solution 2).
Chris' statement of the history is pretty fair. I personally ended up
coming down against AF-style markup both for namespaces and for XLink
because I thought you ended up with ugly, error-prone markup - among
other things, in a Unicode environment, using white-space spearated
tokens is a recipe for interoperability problems. Also I hate hiding
significant markup inside character data or attribute values (which is
why I'm so irritated at the ubiquity of qnames in these places, but I
long ago lost that argument).
And quite a few people on the XLink WG could never understand why it was
a good idea to grandfather HTML's linking idioms, which are
well-established, well-debugged, and effortlessly recognized by software
the world over. Yes, we understood that the HTML WG wanted this to take
place, but when we asked "why does this need to be retroactively blessed
by XLink?" the answer was never compelling enough to convince a majority
to buy into the complexity of doing general attribute remapping when we
had a nice clean lightweight alternative that any language could import
essentially no strain.
Anyhow, all this is history. XLink exists. Someone needs to decide
whether it is fatally flawed and should be deprecated, and if not,
whether it has a useful domain of application, and if so, whether W3C
specifications in that domain ought to be pressured to use it. I
suggest that is is a more productive line of discussion, and I believe
it's one that the TAG is going to take up in the not-too-distant future.
-Tim
|
