Issue: HTTP headers in XHTML Hypertext module.

Hello,

I would like to raise the following issue with respect to Section 13.1
(Hypertext Attribute Collection [1]) of the current XHTML 2.0 Working
Draft:

The current working draft includes a mechanism to specify a mask
for the HTTP Accept and Accept-Language headers, which is commendable.
Judicious use of this mechanism can make it possible to write hyperlinks
which let a user agent navigate to a preferred MIME Type for a resource
or to a variant of a resource using a preferred language.

However, there is also a need for clients to specify additional header
information in order to support the extensibility of the underlying
protocol during hypermedia navigation.

For example, one use case would let the XHTML author specify a logical
range of the target resource that was the subject of interest.  The
author could then write:

<a href='...' hreftype='multipart/mixed'>
  <header name='range'>xpath=//title</header>
</a>

to indicate that the title elements of the target resource are the
target of interest and that they should be represented as an order
list using the Internet MIME Type "multipart/mixed".

Alternatively, the XHTML author could include header information
that associated link-source specific information with the request,
for example a product offer code:

<a href='...'>
  <header name='OfferCode'>XYZ</header>
</a>

In each case, the same effect can be realized using a generative
URI scheme that encodes the relevant information into the URI and
where the URI is then interpreted by the server in order to decode
that information and either deliver the required sub-resources (the
first case) or note some source specific information (the second case).

However, the use of URI encoding of such per-request state makes it
difficult for the designers of hypermedia systems to make use of the
extensibility mechanisms in the underlying protocol.

One way to address this would be to introduce a "header" element that
could be a child of any XHTML element with an @href attribute.  Each
such header element would specify a header name and value that would
be added by the user agent to the request when navigating to the target
of the link.

Another solution would be to allow an extensible list of attributes of
the form href-header-name whose values are a white space delimited list
of the bindings for the named header to be added to the request
formulated by the user agent.  This alternative would require more care
in formulating escaping rules for the attribute values.

[1] http://www.w3c.org/TR/2004/WD-xhtml2-20040722/mod-hyperAttributes.html

Thanks,

-bryan

thompsonbry@saic.com

Received on Friday, 30 July 2004 10:33:26 UTC