HTTP guidelines needed( was Re: Content negotiation example needed.)

There are actually several different points that are raised
from the discussion on content negotiation:

1. What is a "page author"?
2. should WAI authoring guidelines make recommendations about using HTTP
   or any other protocol, and if so how, and should they deserve a separate
section?

Summary:
The bottom line of my opinion is that HTTP is an integral part of "content
providing."
Guidelines regarding HTTP should be included and intgrated like any other
aspect of 
content providing. 

In detail:
In my view a "content provider" should be considered as an entity that
produces 
and delivers "content" over the internet. In particular the content provider 
also provides the content, via HTTP for example, rather than placing it on 
a server that has its own mind, if any.

The internal devision of tasks inside the content provider (writing the text, 
designing navigtion, drawing icons, marking the HTML files) are not addressed 
by the guidelines as guidlines to seperate entities. As far as
standards/recommendations/guidelines are concerened these different aspects
of 
content providing are done by one entity. 

There is no difference between guidelines on HTML and HTTP. In both we say
what the 
output or outcome is. We do not give a step by step guide how to insert alt
text 
in HTML editors.  E.g., we do not have:
1. Assure that your HTML editor supports alt text.
2. Press keys in your keyboard that write the alt text
3. For the exact sequence of key strokes check your editor's documentation.

We do say "every image should have alt text."  The guidelines do not assume 
that HTML is typed in a text editor, and should not assume that. In fact many 
pages are written in a combination of typing and automated manipulation. 
Yet writing the guidelines as if  the "page author" types the HTML that the 
user gets is fine. 

Also the content provider doesn't listen to port 80 and 
types HTTP responses as requests come in. But guidelines should be written 
as if it does.

It should be emphasized that content negotiation or any other HTTP issue is
NOT
server dependent. It is defined in specifications, such as RFC 2616. The
techniques 
document should refer to the relevant sections of the relevant specification
(also in other HTTP issues such as "redirects").

From a practical point of view the techniques document could refer to 
server documentation on applying HTTP in particular servers, such as the 
Apache documentation cited in the discussion. The reason being that the level 
of sophistication might be different in writing HTML in an editor compared 
to configuring HTTP servers.

However, the guidelines/techniques should not present the "page author" as 
an entity that produces pages, and gives them to the "server administrator."

Also the extent that HTTP guidlines should be separated from other is not 
that straightforward. For example when applets are discussed, both the 
authoring of the applets themselves, and writing the HTML the embeds the 
applet in the page are discussed together. It seems more natural, although 
in practice different people may be invoved in the process.

As far as content negotiation goes, the current techniques document is
insufficient. 
An example should include sample HTTP responses (headers and some of the
entity-body)
that should be served depending on different requests. This is similar to
giving HTML 
or CSS fragments.

There are other shortcomings of the current technique document (and
possibly the main guidelines) concerning HTTP, but this deserves a separate
discussion.

Regards,
Nir.

At 01:52 PM 9/14/99 -0400, Chuck Letourneau wrote:
>"1) Instead of including links such as "Here is the French version of this
>document", use content negotiation so that the French version is served to
>clients requesting French versions of documents."
>
>Ok... after reading all the responses and viewing the examples, I can still
>barely imagine that this technique is a "Page Author" responsibility unless
>it could be  interpreted to mean:
>
>[start proposed wording]
>If you create more than one language version or format of a page:
>a) ensure that your Web server supports content negotiation, then 
>b) depending on the requirements of your server, include the appropriate
>markup or name the various files appropriately.  
>See your server's documentation or contact your ISP for further help.
>[end proposed wording]
>
>Some of the example files I looked at modify the file name like this:
> .../filename.html.xx (where xx= nl, en, fr, de, sv, ja, etc.), and some
>use <HTML lang="xx"> while some don't.  
>
>This issue reminds me that there was once a suggestion that the
>Guidelines/Techniques documents have a separate section for HTTP/Server
>Accessibility checkpoints.
>
>Comments?
>
>Regards,
>Chuck
.....
>----
>Starling Access Services
> "Access A World Of Possibility"
>  e-mail: info@starlingweb.com
>   URL: http://www.starlingweb.com
>    Phone: 613-820-2272  FAX: 613-820-6983
> 


===================================
Nir Dagan
Assistant Professor of Economics
Brown University 
Providence, RI
USA

http://www.nirdagan.com
mailto:nir@nirdagan.com
tel:+1-401-863-2145

Received on Tuesday, 14 September 1999 18:06:29 UTC