[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: 'Tim Bray' <tbray@t...>, xml-dev@l...
• Subject: RE: XHTML 2.0 and the death of XLink and XPointer?
• From: Micah Dubinko <MDubinko@c...>
• Date: Fri, 9 Aug 2002 19:36:21 -0700

Hi Tim,

>> * There's no concept of a link that is part of a form
>Well true, but there's no notion of a link that is part of a fish or a 
bicycle either. 

Forms are somewhat more widely deployed on the Web than fish and bicycles
:-)
Google would be a heck of a lot harder to use without forms. I would go as
far as saying the Web as we know it wouldn't exist without forms. This is a
major use case.

>>.. discussion on <object> with three separate linking behaviors ...
>Indeed, the XLink encoding for that would require three subelements
>...Why is packing it all into attributes of a single element a 
>better design?

Two things: 1. In XLink, there's actuate="onRequest" and that's it. There's
no way to distinguish between different levels of user request action, in my
example the difference between a request to follow a link and the request to
view longdesc information.

2. More generally, a common design pattern is to use elements to represent
"things", and attributes to represent properties of those things. In many
cases, the 'link-ness' that needs to be described is a property or
annotation, not a thing. It should be possible to express this natural
structure and still use links.

>>Complex links can't nest properly
>I wasn't aware of that, can you illustrate the problem?

I was thinking of this:
<quote cite="http://www.w3.org/TR/xlink/#extended-link">
Subelements of the simple or extended type anywhere inside a parent
extended-type element have no XLink-specified meaning. Subelements of the
locator, arc, or resource type that are not direct children of an
extended-type element have no XLink-specified meaning.
</quote>

This would seem to preclude nested things, like the <object> tag in XHTML2.
Even splitting out the link parts as subelements wouldn't help:

object element that attempts to load a quicktime movie
  object element that attempts to load a SVG animation
    object element that loads a JPG image/
  /object
/object


Is 'xlink:href' purely an aesthetic issue? I don't know.
But I do hear authors complain about having to type the "long" namespace
declaration, and when they mistakenly type 'href' instead of 'xlink:href',
unhappiness about a silent failure mode.

I see a need for something like HLink. With cooperation and a little luck,
it can complement rather than contradict XLink.

Thanks,

.micah

-- another big snip --

• Follow-Ups:
  • Re: XHTML 2.0 and the death of XLink and XPointer?
    • From: Uche Ogbuji <uche.ogbuji@f...>

• Prev by Date: Re: XHTML 2.0 and the death of XLink and XPointer?
• Next by Date: Re: matching text with regexp in xpath
• Previous by thread: Re: XHTML 2.0 and the death of XLink and XPointer?
• Next by thread: Re: XHTML 2.0 and the death of XLink and XPointer?
• Index(es):
  • Date
  • Thread