Re: two failings of XLink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Hi Norm,
|> 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."

That's what I meant. In fact, I thought that was what I said.

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

I don't believe there are any semantics that hold unconditionally for
every application that might process a document. Editors, in
particular, often treat documents in totally different ways than the
processing expectations of a particular vocabulary might lead you to
expect.

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

I think I agree with you, though I might change the stress a bit. I
agree that presentational languages should use XLink for those
elements that have a presentational semantic. Languages that don't
have a presentational semantic, or those elements that don't have a
presentational semantic, might or might not be good candidates for
XLink. I'm not prepared to say that they never are, only that they
might not be.

|> 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).

Sounds reasonable, I think.

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

<shrug/>

Most technologies have limitations and impose design restrictions on
their users. Sometimes the practical benefits of a technology are
sufficient to justify working within the design limits imposed,
sometimes they aren't.

Personally, I think longdesc is bad design. I favor changing its
design independent of the XLink limitations. As it happens, the
designs I'd favor would not be in conflict with the limitations of
XLink. I think that's a coincidence.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | It is a general error to imagine the loudest
XML Standards Architect | complainers for the public to be the most
Sun Microsystems, Inc.  | anxious for its welfare.--Edmund Burke, 1769
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE9mF8TOyltUcwYWjsRAkvsAKCCJeVJxUR6NCeSWaKU0cDL1eHEeACeOm9/
oFnL0P75Hgt0jtx6lh42XoQ=
=wdVb
-----END PGP SIGNATURE-----

Received on Monday, 30 September 2002 10:27:05 UTC