Re: Disclaimer for Authoritative Metadata (ACTION-793)

* Larry Masinter wrote:
>"Specifications MUST NOT work against the Web architecture by requiring
>or suggesting that a recipient override authoritative metadata without
>user consent."
>
>but in the end, "user consent" adds:
>"Likewise, consent may be implied by the nature or type of interaction
>being performed by the agent".
>
>In fact, there are no current W3C or IETF specifications that "work 
>against" the "Web architecture" in this way. The one WHATWG 
>specification on sniffing does not REQUIRE sniffing (it's an option). It 
>does suggest that a recipient override authoritative metadata, but the 
>suggestion could change to make "running a modern browser in non-debug 
>settings" a type of interaction that implies user consent to sniffing.

XSLT processors are required to treat `image/png` as `application/xml`
when evaluating the `document(...)` function, with no requirement to
make the user aware of this behavior and no requirement to allow users
to control this behavior, and as far as web browser implementations of
XSLT are concerned, there can be no implication of consent on part of
the user of the web browser in this regard.

The user of a stand-alone XSLT processor could be assumed to be the
author of the XSLT document, and in that case consent could be implied,
but that is not the case for web browser implementations, if you take
the user of the web browser as the only relevant user. In practise, web
browsers tend to serve more than one master, and increasingly so, which
might make for an interesting TAG issue...

But the logic here is simply that `document(...)` implies a context that
suggest "treat-as-xml", pretty much the same way that `<img src='...'/>`
implies "treat-as-image", or that `<link rel='stylesheet' href='...' />`
implies "treat-as-stylesheet", with all the implied "do-what-I-mean" and
"don't-do-what-I-don't-mean" and lots of friction where the two overlap.

For reference, <http://www.w3.org/TR/xslt#function-document> says "The
data resulting from the retrieval action is parsed as an XML document
regardless of the media type of the retrieval result", and for XSLT 2.0
<http://www.w3.org/TR/xpath-functions/#func-doc> says the same, "If the
top-level media type is known and is "text", the content is parsed in
the same way as if the media type were text/xml; otherwise, it is parsed
in the same way as if the media type were application/xml."

This example is pretty explicit, for "suggesting" it should be enough to
simply not discuss media types at all; you could try, for instance, to
find where the current XML 1.0 Recommendation says `image/png` resources
should not be treated as external parsed entity when so referenced.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 7 April 2013 01:40:20 UTC