Re: [XHTML2] Linktype 'redirect' and an idea for a finer grained version of it

> [Original Message]
> From: David Woolley <david@djwhome.demon.co.uk>
>
> > As for my proposal, it differs from Refresh in two significant ways.
>
> I don't, unfortunately, have time to write up all my thoughts on this
> at the moment, but, if one accepts there is a use case for HTML based
> redirects (as against server side redirects and HTTP mediated client
> side redirects) and then that there was a case for fragment based
> redirects, I would suggest that:
>
> - user agents be mandated not to redirect based on any element that
> would not be visible in an unstyled and unscripted interpretation of the
> document (and as far as possible to extend this to styled and scripted
> interpretation).  This is to ensure that anyone given (or saving) a
> reference to the whole page for the purpose of accessing a redirected
> fragment should not just find that the fragment had disappeared (even
> if the document were viewed in hard copy).  This is a result of similar
> principles to those that require that a client side HTTP mediated 
> redirect should include a payload describing the redirection in
> human readable terms.  It would mean that link was not an acceptable
> vehicle for such redirections.

An interesting point.  One way of addressing it would  require that
instead of extending just the <link> element that it be done via any
element that used rel="xref" href="...".  However, this would sacrifice
the ability to determine the crossrefs from looking at just the <head>.
At that point, the utility of the proposal would be greatly reduced.

There is also one  weakness in my proposal.

Let's examine a real world use case.  It is proposed that when the
CSS 3 Box Model reaches CR stage that the box-sizing property
should move there from its current place in CSS3-UI.  CSS3-UI
should be updated then to reflect the move and a redirection
scheme internal to the document would be useful. However there
will be two URL's that refer to this:
  http://www.w3.org/TR/css3-ui/#box-sizing
and a version specific URL such as (example only):
  http://www.w3.org/TR/2005/CR-css3-ui-20050505/#box-sizing

What would be nice would be a way to embed in the document
the ability to go from different incoming URL's to different outgoing
URL's.  I think what is needed to support this is a new attribute
for the Hypertext collection, named for example rhref.

Thus for example, combining this with David's point we could have:

<p id="box-sizing">The box-sizing property has been moved to the
<a xml:base=" http://www.w3.org/TR" rhref="/css3-ui/#box-sizing"
href="/css3-box/#box-sizing">CSS3 Box Model</a>
module as of the <a xml:base=" http://www.w3.org/TR/2005/"
rhref="/CR-css3-ui-20050505/#box-sizing"
href="/CR-css3-box-20050505/#box-sizing">5 May 2005</a>
version.</p>

The intent is that xml:base would also apply to rhref and that
the automatic redirection would only apply if the incoming URL
matches rhref. The sequence of expected actions in this case
would be as follows:
1) Head to the element whose id matches the hash portion of
the incoming id. (If no such element, 
2) For the first element encountered in a preorder traversal
of the document tree from that point whose rhref matches
the incoming URL, do a automatic redirection to the URL
 indicated by href.

This would work. However, as I pointed out earlier, if the point
of redirection is moved out of <head> and into <body>,
the utility of any such scheme would be greatly reduced.
It would save very little time compared to manual redirection,
and complicate what would be expected of an XHTML2
user agent.  Thus I would have to recommend against
any scheme for automatic redirection that does not restrict
potential instructions for redirection to <head> a la

<link rhref="#chap12" href="chap12.xhtml" />

where instruction 1 above would be replaced by using
<head> as the starting point for the preorder traversal.

Received on Thursday, 27 November 2003 14:14:05 UTC