Re: The Return of "WaSP Asks the W3C"

* Dominique Hazaël-Massieux wrote:
>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.

Either there is a specification that ensures such behaivour or there is
no such specification. If there is, application/xml can be considered an
alternate MIME type for XHTML documents, if there is not it cannot be
considered an alternate.

>> 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?

  ...
  Since MIME dispatchers work off of the MIME type, use of text/xml or
  application/xml to label discrete media types will hinder correct
  dispatching and general interoperability.
  ...

Something is not interoperable just because it works in some browsers.
It seems perfectly reasonable for a search engine robot to skip all
application/xml documents when it only supports HTML/XHTML.

>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...

As a content provider, I care about user agents other people use and I
do not want that my content causes unexpected behaivour which I would
risk when relying on undefined behaivours.

>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).

In response to my last call comments, yes. However, as long as RFC 3023
does not get updated, interpretation of fragment identifiers for
application/xml is undefined and it is thus not reliable to use this
type if fragment identifiers are involved.

>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

As much as any XHTML Family document may be served as 'text/plain' or
'application/octet-stream'.

>> 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:

Because RFC 3236 does not allow it.

Received on Friday, 5 September 2003 19:22:15 UTC