Re[2]: Proposed TAG Finding: Internet Media Type registration, consistency of use

At 05:33 AM 2002-05-30, Steven Pemberton wrote:

>From: "Tim Bray" <tbray@textuality.com>
>> Anyhow, for the moment I stand by the position that sniffing is always
>> without exception bad when you're figuring out how to do top-level
>> dispatch.  It opens horrible security holes and when breakage does
>> occur, it focuses the blame away from where it belongs, namely people
>> who screw up in configuring their webservers.
>
>I think this is the major problem: it protects the guilty, and penalises the
>innocent.
>
>I have long wanted to be able to write web-based tutorials along these
>lines:
>
>    Here is an HTML document to illustrate this technique:
>        http://www.cwi.nl/~steven/test/img-test.html
>    and here is its source: http://www.cwi.nl/~steven/test/img-test.txt

On second thought, one might by now conclude that you shouldn't be wishing to do that.

If the corrective pressure has to come from what the author and user can recognize as their interests, this implementation-plan is flawed.  From the perspective of anything that can be validated by the author or the user, both of the above are indeed the same resource.  What you mean to create in terms of a semantic interaction is that the second reference is supposed to evoke an alternate view of the same resource as was presented (in a default view) in the first reference.   The distinction you wish to make is indeed _what to do with it_ and not _what you meant_, at the level of the sample page which is the exhibit for this step.  The sameness of the source, as well as the difference in the view, is essential to the sense of the lesson.

So perhaps a better place for this distinction to be expressed (looking forward) is by different default actions in two instances of an XLink and not in different URIs suggesting different resources. 

With the new tools, we might could do what you want.  But it's because we have a segmented expression of the resource and what to do with it.

Al

PS:

Source view, like the back button, is something the browser provides and the user should know about.  The web tutorial should train for both of these browser functions.  

http://www.w3.org/TR/UAAG10/guidelines.html#gl-content-access

And because it is there in the de_facto profile of browser functions, carrying error-control load, type-control orthodoxy _to provide a source view_ is never going to generate enough user interest to provide traction for the issue.


>but I can't, because in IE you get exactly the same results for the two
>links (try it on the above). How can I get IE to do the right thing? I
>can't! It *always* presents my file served as text/plain as if I had served
>it as text/html. It prevents people from doing the right thing...

How committed are the consumers of your web-based tutorials?  Are they casual Web walk-ons, or have they enrolled in something?

Two out of the three browsers I happen to have installed do this the way you want.  The other two are readily available for free.  In some educational situations[1], asking the users to install some client or client extensions is de_rigeur.  You don't have to specify the browser, just the standards compliance profile that they meet, and you can inform your customers of know non-compliant configurations.  That is why I ask how persistent is your relationship with the learners.

If the dominant player does something wrong, this is an problem of enterprise proportions for the Web.  But still, it is not clear that the TAG list is the place to pursue a specific beef against a specific implementation.  If that is all we are dealing with, we don't need to wrap it in the trappings of TAG findings and architectural principles.

In this case, control by user supervision alone is inadequate.  Users accept the unquestioned 'upgrade' to HTML processing in such proportions that this behavior is what the market will bear.  The system is showing not enough stiffness against violating _what the author said and expects to happen_.

We need both a stiffer control loop around what the servers serve as type information, and a more faithful response from user agents.  These are interdependent.  So we need a roadmap for a closed-loop transition practice that will migrate the operating point to where we would rather be.  This does sound like a 'delegate to QA' perhaps.

I do hope we can resolve this without having to introduce a !important on HTTP headers...

Content-Type: text/plain ;sic

Al

[1] a category of situations distinguished by [recognizable by] business rules.

>And if IE thinks your tar archive is an HTML file, well bad luck for you and
>your users.
>
>It would be *really really good* if IE offered an option to switch off
>content switching, and even a dialogue, so that people could get an idea
>that something was wrong:
>
>    This document has been served as text/plain but looks like an HTML file.
>    What do you want to do:
>        [ ] View it as HTML
>        [ ] View it as text
>
>    [ ] Never ask me this question again.
>
>Steven Pemberton

Received on Thursday, 30 May 2002 12:49:24 UTC