[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XHTML 2.0 and the death of XLink and XPointer?

• To: "Christopher R. Maden" <crism@m...>
• Subject: Re: XHTML 2.0 and the death of XLink and XPointer?
• From: Tim Bray <tbray@t...>
• Date: Tue, 13 Aug 2002 09:34:19 -0800
• Cc: xml-dev@l...
• References: <4.3.2.7.2.20020812123854.02479a00@m...> <5.1.0.14.0.20020813043239.040a1ec0@m...>
• User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020722

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

• Follow-Ups:
  • RE: XHTML 2.0 and the death of XLink and XPointer?
    • From: "Jelks Cabaniss" <jelks@j...>
  • Re: XHTML 2.0 and the death of XLink and XPointer?
    • From: "Simon St.Laurent" <simonstl@s...>
  • XLink and XML specs (was Re: XHTML 2.0 and the death ofXLink and XPointer?)
    • From: Mike Champion <mc@x...>

• References:
  • Re: XHTML 2.0 and the death of XLink and XPointer?
    • From: Ann Navarro <ann@w...>
  • Re: XHTML 2.0 and the death of XLink and XPointer?
    • From: "Christopher R. Maden" <crism@m...>

• Prev by Date: Transform XML and Stylesheets
• Next by Date: RE: Transform XML and Stylesheets
• Previous by thread: Re: XHTML 2.0 and the death of XLink and XPointer?
• Next by thread: XLink and XML specs (was Re: XHTML 2.0 and the death ofXLink and XPointer?)
• Index(es):
  • Date
  • Thread