FW: please reivew mobileOK Basic Tests 1.0

I find this an extremely vexed question and I do not think the answer is
at all obvious. 

Is it acceptable practice to point an IMG element at a resource that can
vary its representation? Definitely yes, as long as its representations
are acceptable for an image. Especially as we recommend that the image
is resized and reformatted as necessary at the server to suit the
delivery context.

Now let's consider a resource whose representation can vary beyond image
to html. That is fine from a thematic consistency point of view. It is
also, probably, fine as a reference from a hyperlink, but doesn't seem
like it is acceptable as reference from an image element. 

It seems perverse to me to say that a content author, knowing that the
preferred rendering of a resource is html, can then use an image element
to point to it. In this case my feeling is that since an image is
required, and although it is possible that in other contexts the same
image is a thematically consistent representation of something else, in
this case it is not. 

It is intrinsic to its use that the resource must be an image. The URI
should reflect this to distinguish this use of the resource from use of
the resource in other circumstances.

In short, relying on content negotiation to give you different
representations of the same resource in the same context seems
absolutely fine, that's what it is there for. Relying on it to yield
semantically different versions of the resource doesn't seem fine at
all, in fact seems quite wrong to me. The checker should point that out.

To illustrate this further:

Consider the OBJECT element. It's perfectly fine for an author to
include an image using the OBJECT element (in practice you have no
choice for SVG, I think). Indeed the text of HTML 4.01 makes it clear
that OBJECT subsumes the functionality of IMG. When fetching the content
for an object we say that the full range of acceptable content types is
sent, even when there is a type attribute on the object, because the
type attribute is not mandatory and because the description of the type
attribute makes it clear that a different content type might be yielded.

Consider further the LINK rel=alternate mechanism ...

In summary: I am opposed to making the change suggested and think we
need to move on from this subject.

Cheers

Jo

-----Original Message-----
From: Sean Owen [mailto:srowen@google.com] 
Sent: 01 October 2007 17:45
To: Laurens Holst
Cc: Jo Rabin; mike@w3.org; public-bpwg-comments@w3.org
Subject: Re: please reivew mobileOK Basic Tests 1.0

I am inclined to change the behavior that is stated, yes. I am
convinced by the example you give Laurens, that it could be a problem,
even if I have never heard of any resource actually delivering XHTML
vs. PNG selectively and expecting the former to work when referenced
via img tag. Still that's a best an argument that it won't matter in
practice, and that the tests will sort of "accidentally" uncover sites
that are trying to do this, which I think should be warned against
actually. Uh oh, maybe there's another debate. So I return to this
argument that this is not going to matter much if at all, and that
where it does, it will in fact highlight problematic behavior (though
it may be inducing it inadvertently, and, this was not something that
was intended originally to be tested as part of mobileOK-ness).

I do think there remains a question of whether this is adjusted now or
later. We've effectively had a version 1.0 out since the start of the
year, and now 1.1, and now 1.2... except 1.0 isn't actually out yet.
*If* this alone would trigger months more of deliberation... we may
simply have to draw a line at what's absolutely necessary to fix and
hold up publication and what is not. But you are right that it may
well not. So let me say I would like to see this adjusted as you
describe and agree there.

On 10/1/07, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> Sean Owen schreef:
> > I still don't think this is "wrong" per RFC 2616. The client is
> > listing content types it knows about and the server is responding
with
> > one of those content types. Sending an image when a stylesheet is
> > expected is a serious application error, not quite a problem with
> > Accept.
> >
>
> You have to realise that HTTP is stateless and works on the level of
> individual requests. There is no such thing as indicating what is
> supported by a 'group of requests' as made by the browser. The client
> indicates "media types which are acceptable for the response" (RFC
2616
> section 14.1) in its requests. For requests generated by an <img> tag,
> text/css and application/xhtml+xml clearly aren't.
>
> > That said, points well taken. Firefox for example will restrict the
> > content types it lists when requesting an image (though the initial
> > request for the page is going to list most everything it
understands,
> > since the URL could resolve to a lot of different things.)
> >
>
> And the browser can also display all those things. Were the browser
only
> able to show PNG images in the body of HTML pages and not stand-alone,
> it would not include image/png in the request header.
>
> > I don't quite get the point about content negotiation -- what's the
> > situation where a correctly-behaved server does the wrong thing
> > because some irrelevant types were listed in Accept? Returning an
> > image for a stylesheet is not an HTTP header problem, though it
> > wouldn't have hurt if the client reminded the server of that in the
> > Accept header, sure.
> >
>
> Of course, the applications of text/css and image/jpg are kind of
> disjunct, so it's not likely a single resource can be represented by
> both of those.
>
> However, an image can be delivered in several versions, e.g.
image/jpg,
> or application/xhtml+xml for a version that shows the image with its
> meta-information in HTML and previous/next navigation links, and even
> text/plain for a version containing the text inside the image, or
> converted to ASCII-art. These can all be considered different
> representations of the same resource (and thus, the same URL).
>
> Given this, you could easily arrive in a situation where the <img> tag
> gets the application/xhtml+xml representation because it is listed in
> the Accept header and considered superior by the server (because it is
> more user-friendly), even though it is not an acceptable content type.
>
> I could sketch more situations, but the matter of the fact is that the
> Accept header needs to indicate what content types the request can
> accept, and the system of content negotiation can only work if this is
> indicated correctly. If the Accept header does not contain the correct
> information, then at some point it will cause problems with web sites
> that use that HTTP functionality.
>
> > One small issue is that changing this causes a fourth round of last
> > call comments. As last time the practical argument is "it's not
wrong"
> > and probably matters little, even if it could be improved. It's a
moot
> > point if we are fortunate (?) enough to need more substantive
changes
> > anyway. Otherwise... let's come back and cross this bridge when we
get
> > there.
> >
>
> Well I raised the issue earlier than today :).
>
> I disagree with the statement that "it's not wrong". It is wrong,
> definitely. However, it will not cause problems on sites that do not
use
> content negotiation (because the header is ignored), and on those that
> do, most will probably deal with it in a way that the result coincides
> with what you really want. So if you want to say that this probably
> won't cause problems often, then that would probably be correct
> (although I don't have a crystal ball).
>
> But I still think it should be fixed. I would hate it if even a single
> site would have to remove a nice content negotiation system because
> otherwise they can't get that mobileOK label that management wants.
>
> By the way, I don't know if you should consider this a 'substantive
> change'. Seems more of a bug-fix to me.
>
> Responding to Jo's comments:
> > And I am not actually convinced that "just because existing browsers
do
> > it" is a prima facie case for a checker doing it. We don't after
all,
> > follow meta refresh links etc.
> >
>
> A checker can't check for correctness of the response if it sends
> incorrect requests. So it's pretty relevant.
>
> > So on that theme, the two extremes of outcome from sending headers
the
> > way we suggest are:
> >
> > a) it makes no difference
> > b) the server, for whatever reason, turns out to have (e.g.) a css
file
> > that gets served instead of the image for some particular URI.
> >
> > If you were the developer of the site you'd want to know that.
> >
>
> It's legal behaviour, given the headers that are sent by the mobileOK
> test, so there is no error in the site's code and thus no reason to
> alarm the site developer by throwing a false error. Or rather, a true
> error, but one in the UA (the test) and not in the site's code.
>
> Now if the test would send the proper Accept headers, and you would
get
> a text/css file in return, then yes, that's probably something you'd
> want to know. As I said before, it's good that the test now checks the
> MIME type and content of the response to <img> requests.
>
> Well anyway, I hope I have provided enough explanation to show how
HTTP
> functions. Looking forward to this problem getting fixed. I'll keep an
> eye on the specification, and what happens next.
>
>
> Regards,
>
> Laurens Holst
>
> --
> Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Laurens Holst, student, university of Utrecht, the Netherlands.
> Website: www.grauw.nl. Backbase employee; www.backbase.com.
>
>
>

Received on Tuesday, 2 October 2007 11:50:16 UTC