Re: The Return of "WaSP Asks the W3C"

Le ven 05/09/2003 à 06:06, Bjoern Hoehrmann a écrit :
> The document seems to identify tag soup as something bad. I would agree
> in theory, but as a matter of fact, XHTML only works in some browsers
> because they interprete the document as tag soup. XHTML documents break
> in conforming HTML user agents. So without tag soup parsing, no XHTML.

... *in some browsers*! Besides, there is a huge difference between any
random semantic-less tag soup and a well-defined set of contraints that
are known to work with most HTML user agents.

> I disagree that application/xml is an alternate media type for XHTML
> documents.
> 
>   * XHTML user agents are not required to support this MIME type (of
>     course, they are neither required to support text/html or
>     application/xhtml+xml ...)

The fact that they aren't required (which they should be, but that's
another matter) to support this MIME-type doesn't prevent them to
actually do so.
 
>   * MIME type sniffing is considered bad practise, you can read long
>     threads about it on www-tag where people complain that IE treats
>     text/plain documents sometimes as text/html documents. If you
>     deliver XHTML documents as application/xml you would either not
>     get the results you want or you rely on MIME type sniffing which
>     is a bad thing.

MIME Type sniffing consists in overriding the decision that you would
have taken by looking solely at the MIME-type by the decision you take
by looking at the content. Interpreting an XHTML document served as
application/xml as XHTML is NOT MIME type sniffing, given that the
decision of handling the document as XHTML only completes the decision
of handling it as XML.

>   * Even if MIME type sniffing is bad practise for some types and good
>     practise for other types, it is undefined how to determine whether
>     an application/xml document should be treated as some sort of
>     application/xhtml+xml.

Indeed, there is no official XML processing model, although there is
broadly shared interpretation that a "generic" XML processor could rely
on the namespace of the root element to determine what XML language is
concerned.

> Appendix A.1 of RFC 3023 explicitly warns
>     not to do that or worse rely on specific behaivour in this regard.

Err? I just read the appendix and don't find anything that would suggest
this?

>   * And if it was defined you would get results you do not desire in
>     some situations, i.e., if you do not want a user agent to apply
>     any kind of special processing for known document types.

Well, given that the processing model for a generic XML processor isn't
defined, it's up to the user agent to do the right thing, which is
probably something along:
- if you're a browser, processing it smartly is better than displaying
the code
- if you're a user agent whose usage wouldn't benefit from processing
the document as XHTML, don't do it

Neither breaks conformance, even though neither behavior is required.
Results "you" do not desire is a bit unclear; you get the results that
you desire, provided you use the user agents that meets your desires...

>   * And even if this weren't issues, fragment identifiers are undefined
>     for application/xml while they are defined for application/xhtml+xml
>     you could thus get all sorts of unexpected results like fragment
>     identifiers do not work or work differently than you expect.

I probably won't learn you anything by telling you that XPointer (the
to-be-RFCized fragment identifier specification for XML) is backwards
compatible with the fragment identifiers mechanism currently defined by
XHTML (and that XHTML MIME Type RFC explicitely makes reference to it).

> Hence, for theoretical and practical matters, the document should say
> that application/xml should not be used for XHTML documents.

Note that the XHTML Media types note says:
"Any XHTML Family document MAY be served as 'application/xml'."
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801

> I find it quite troublesome to refer to "content negotiation" in this
> document as the "solution" does not serve different content (which
> content negotiation is about) 

Well, it does; the MIME-Type is not dissociable from the content it
marks.

> and the proposed solution for the Apache
> web server, i.e. using "AddType application/xhtml+xml;qs=0.8" would
> cause the web server to create an invalid HTTP response as it would send
> out the 'qs' parameter which is not allowed for application/xhtml+xml.

I don't why it would be invalid:
"Parameters may be required by their
   defining media type or subtype or they may be optional.  MIME
   implementations must also ignore any parameters whose names they do
   not recognize."
http://www.ietf.org/rfc/rfc2046

Although I dislike the idea that Apache sends this parameter solely used
for internal processing, it's not invalid, merely ugly.

> It is also noteworthy that browser support for XHTML is, well, not
> perfect.

Sure, but let's give time to time... I don't think many technologies
have ever been implemented perfectly, and even less so during the first
years of their deployment. 

(FWIW, I'm not really sure this technical/theoretical discussion belongs
to public-evangelist@w3.org, it would probably be more appropriate in
www-html or www-qa for the conformance topics)

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org