W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2000

Checkpoint 8.6 (link information)

From: Ian Jacobs <ij@w3.org>
Date: Tue, 08 Aug 2000 22:54:23 -0400
Message-ID: <3990C7DF.FEDA7D9E@w3.org>
To: w3c-wai-ua@w3.org
Hello,

Per my action item from the 3 August 2000 teleconference [1],
please consider this change to checkpoint 8.6 (refer
also to original proposal [2]). In the 28 July draft [3],
checkpoint 8.6 reads:


   <OLD>
    8.6 To help the user decide whether to follow a link, 
    make available to the user the following information: 
    link content, link title, whether the link is internal, 
    whether the link has been followed, whether following it
    may involve a fee, and information about the type, size, 
    and natural language of the linked Web resource.
       Note: User agents are not required to retrieve the 
       Web resource designated by a link as part of
       computing information about the link. 
   </OLD>

The issue I raised was whether this list should include
size since that would probably required an HTTP request,
which is what the Note says is not required. On this
topic, Tim Lacy reports [4] that:

  "HTTP:HEAD can't be scripted, it has to be sent directly
  (read: binary).  What you get back will depend on what 
  the server is capable of telling you.  It will not in 
  any known scenario return the number of bytes that a link 
  will return, because it doesn't recurse.  Byte count will
  reflect the HTML and text only, no images, count of images,
  etc. The only way around this would be to execute some code 
  at the server that would load the requested page to a local 
 (to the server) page, and count the bytes as that happened, 
 returning that to the requestor."

I also spoke to Henrik Frystyk Nielsen, co-author of HTTP/1.1 [5]
who confirmed that HEAD isn't recursive. Therefore, the size information
you get is about a particular "manifestation" of a single resource
designated by a single URL.

I also glanced at (i.e., did not read in detail) the XLink
Specification [6] to find out whether our link requirements make
sense in light of that specification. In XLink, a link may have 
more than one "end". And some links may not be traversable.
I may have to read the XLink spec to have more confidence about
how it affects checkpoint 8.6.

<NEW>
    8.6 To help the user decide whether to traverse a link,
    make available the following information about it: 
    link content, link title, whether the link is 
    internal to the local resource, whether the user has
    traversed the link recently, whether traversing it
    may involve a fee, and information about the type, size, 
    and natural language of linked Web resources. The user
    agent is not required to compute or make  
    available information that requires retrieval 
    of linked Web resources.
</NEW>


Notes:

0) Applicability is in force here. For example, some links
   that use xlink may not have link content.

1) Add XLink to list of references. In XLink links have a title,
   type, role, etc.

2)  The word "traverse" is defined in the XLink spec, 
    and so I use it here instead of "follow".

3) Add something like the following to the techniques
   document:

 - User agents should cache information determined as the
   result of retrieving a Web resource and should make it
   available to the user. Refer to HTTP's caching mechanisms
   (i.e., read that spec).

 - Size is not required to be recursively cmoputed.

 - Recently is determined by the user agent. The user agent
   may allow the user to configure this parameter, and should
   allow the user to reset all links as "not followed recently".

 - User agents may use HTTP HEAD rather than GET.
   Point to HTTP headers that may be used for size, content language,
   content type.

 - Some markup languages allow authors to provide hints about
   the nature of linked content (e.g., in HTML, the "hreflang"
   and "type" attributes on the A element). Specifications for
   should indicate when this type of information is a hint
   from the author and when these hints may be overridden by
   another mechanism (e.g., HTTP headers). In such cases, user
   agent developers should provide "real" information when 
   available (e.g., after caching a request) and may provide
   "hint" information prior to making a request to the server.
 

 - Ian

[1] http://www.w3.org/WAI/UA/2000/08/wai-ua-telecon-20000803
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0067.html
[3] http://www.w3.org/WAI/UA/WD-UAAG10-20000728/
[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0211.html
[5] http://www.ietf.org/rfc/rfc2616.txt
[6] http://www.w3.org/TR/xlink/
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Tuesday, 8 August 2000 22:54:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:14 GMT