W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2005

Re: Serving XHTML as XML

From: Jim Ley <jim.ley@gmail.com>
Date: Wed, 23 Feb 2005 13:17:11 +0000
Message-ID: <851c8d3105022305175ab7247c@mail.gmail.com>
To: w3c-wai-ig@w3.org

On Wed, 23 Feb 2005 13:32:53 +0100 (CET), Tina Holmboe
<tina@greytower.net> wrote:
>  Returning for a moment to your algorithm. You say:
>    'All  we  need  to do is to test if the accept-header sent by the
>     browser, etc., contains the string "application/xhtml+xml".   If
>     it   does,   we   send   it file   A,  XHTML  1.1  and  mime-type
>     application/xhtml+xml, if it doesn't we send it file B, XHTML 1.0
>     Strict and mime-type text/html.'
>  While ignoring for a moment the q parameter, this sounds to me wrong.

Tina, you never returned to the q parameter - you absolutely cannot
ignore the q parameter, See RFC 2616 definition of the q parameter
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.9  a value
of 0 - specifically says that it is not acceptable to the client.  So
the algorithm described in the document specifically violates RFC
2616, I hardly think that is something that ever be ignored even for a

There are lots of php scripts knocking about to do what the author is
intending, I've yet to see one which works to RFC 2616 (The apache
module does of course, so if you wanted to send content negotiated
content you could)

I also don't understand why you'd send XHTML 1.0 sent as text/html why
not stick with the 1.1 - there's no standards violation by doing so,
and you're using the latest mark-up rather than XHTML 1.0.

Of course, I also agree with all of Tina's other points.


Received on Wednesday, 23 February 2005 13:17:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:31 UTC