W3C home > Mailing lists > Public > www-tag@w3.org > September 2002

Re: two failings of XLink

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 30 Sep 2002 14:00:49 +0100
Message-ID: <167338081104.20020930140049@jenitennison.com>
To: www-tag@w3.org, Norman Walsh <Norman.Walsh@sun.com>

Hi Norm,

> | So can you describe more formally what you class as a hypertext
> | reference as opposed to a URI that is not a hypertext reference?
>
> This strikes me as the sort of question where, no matter what answer
> you give, someone will construct an edge case that's neither in nor
> out of the boundaries drawn.

Why do you think I asked it :) Anyway, even a fuzzy definition should
help us say "these URI references definitely should not use XLink" and
"these URI references definitely should use XLink", leaving the ones
in the middle as being up to the markup language designer.

> Here anyway is an attempt at a practical definition:
>
> 1. A hypertext references is a reference to something that if traversed
>    will be displayed to a human reader. (So references to stylesheets
>    and script libraries are not hypertext references.)

I think that there are two potential issues with that as a definition,
at least as a definition that would help us work out whether XHTML
should use XLink for a reference to a particular resource.

First, the content type of the resource at the other end of the link
doesn't determine the way in which the resource is used by an
application. As Mark Baker pointed out, a link to a stylesheet might
be used in order to style a document or the stylesheet might be
displayed to the user. That would prompt me to change the definition
to:

  "A hypertext reference is a reference that, on traversal, should
   result in the referenced resource being presented to the user."

The second thing is that with most markup languages, the way in which
a particular URI is used by an application really depends on the
application that processes the XML document. This is true for XHTML as
well -- a browser might not display the stylesheet associated with a
document to the user, but an editor or a web visualisation engine
might.

So I think that this effectively says that hypertext references (and
hence XLink) should only be used in markup languages that define a
fixed presentational semantic. For example, they should be used in
XSL-FO but not in XSLT (XSLT has a fixed processing semantic, but it's
not a presentational one). Markup languages such as XHTML, MathML and
DocBook should use hypertext references (XLink) for those elements
that have a presentational semantic and where the referenced resource
should be presented to the user, but not on those elements that do not
have a presentational semantic. For example, MathML should use XLink
on the elements in the presentation side of the language, but not in
the content side of the language.

> 2. A hypertext reference is something you can type into a browser.
>    I think this limits it effectively to a single URI reference (no extra
>    parameters that can't or aren't encoded in the URI).

In other words, a hypertext reference results in a GET request in
HTTP, never in a POST or PUT. Presumably it shouldn't result in a
DELETE either, so perhaps we should also say

  "A hypertext reference is one that retrieves a resource."

That would rule out PUT and RESTful uses of POST (though not by itself
uses of POST that are actually GETs with extra information added).

I think that these guidelines would mean that XForms is right not to
use XLink to reference the instance or schema for a particular form.
Maybe they'd also be enough to resolve the issue for XHTML as well, if
the <object> element were reworked so that an xlink:href attribute
could be used to retrieve both applets (which I count as things that
are presented to the user) and other media (such as images and
movies).

It doesn't scope-away the classic example of:

  <img src="someURI" longdesc="someOtherURI" />

though, because in this case both resources are retrieved for
presentation to the user. I don't think that "you shouldn't design a
markup language like that" is a good enough answer to this problem,
but then I don't think that any technology should be prescriptive
about the design of a markup language.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Monday, 30 September 2002 09:08:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:11 GMT