AW: Type Attribute

Lachlan,

> Hi,
>   This is a general question related to virtually the entire thread 
> rather than a reply to anything specific.  I think this fairly well sums 
> up most (not necessarily all) of my problems with @type.
> 
> -- Question --
>   If, when using the HTML 4, advisory type attribute, the requested 
> resource does not necessarily have to match the type specified, then how 
> can the attribute be accurately used for making the decision of whether 
> or not to retrieve the resource?

it can't *accurately*. 
it doesn't even need to. as it's meta information, the UA *may* use it to make this decision.
if anybody could guarantee that the value given in @type was always correct (=corresponds to the mime type of the resource located by the URI), then we'd probably seen a different handling of @type long ago.

with a prescriptive @type, what would a wrong value do? having the UA request a file that's not there, even if the URI is correct. not much better either, is it?


> -- Example Use Case --
> 
> -- Assumptions --
> * HTTP1.1, or other protocol that supports content negotiation, is being 
> used
> * A UA will not include in its request header, any content type it does 
> not support

i would love to continue this discussion focussed on XHTML 2.0 instead of HTTP - which would mean that examples should no longer assume HTTP as the underlying protocol. because of its popularity, it's too tempting to rush to conclusions that seem right with HTTP - and are right with HTTP only. if we'd concentrate on FTP, ed2k etc., we'd stay more generic.

what we're talking about more and more is the use of canonical URIs with HTTP, not the design of an XML-based document markup language.

still, let me see what we can do:

> -- User Agents --
> Three example UAs will be used.
> UA 1. Supports both image/gif and image/png.
> UA 2. Supports image/gif only.
> UA 3. Supports image/png only.
> 
> -- Use Case Description --
> * A resource: "image.gif" is of type "image/gif".
> * The canonical URI "http://www.example.com/image" refers to that 
> resource.
> * An  author writes the following:
>    <span src="http://www.example.com/image" type="image/png">image 
> description</span>
> * The author only uses UA 1 to check and view the document.
> 
> 

@type as meta-info:
===================

* UA1 will request and display the image. there will not be an error message(!!): the author expressed he wanted to display whatever "http://www.example.com/image" returned. (had he really wanted a PNG and only a PNG to be displayed, he'd have used  "http://www.example.com/image.png" instead.) @type was a hint for the browser and did not express the author's intention to display "image/png" and nothing else then image/png. therefore, as in HTML 4.01, once the file is retrieved, its mime type takes precedence and there is no need for an error message.

* UA2 may or may not request the image. if it does, it will also display it. again, there will be no error message in this case. if the UA chooses not to request the file, it will use the provided fallback.

* UA3 will request the image and present a message to the user (need a plugin, error message, whatsoever). depending on the user input (get plugin? stop processing the document?) it will either use a fallback mechanism or allow the user to take some other action to make the already downloaded file visible.


this differs slightly from the "advisory" and "descriptive" scenarios, mainly in that UA1 will never indicate an error (which i believe is a reasonable way to deal with the situation).


regars,
oskar

Received on Saturday, 22 November 2003 16:12:11 UTC