Re: Type Attribute

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?

-- Example Use Case --
  This use case covers all three cases of having the 'advisory', 
'prescriptive' and 'descriptive' type attributes.  These will follow my 
inteded meaning of the definitions I gave in my previous post to this 
thread.
  This DOES NOT cover the questions of whether @type should be single- 
or multi-value, or whether q-values should be allowed.  The following 
example will still work, regardless of the answers to these questions.

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

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


**-- Advisory Type Attribute --**

UA 1.
* Supports image/png
* Requests resource with default Accept header
* Server returns image.gif as "image/gif"
* Supports image/gif and renders the image

UA 2.
* Does not support image/png
* Decides not to request the resource
* (Does support image/gif and could have requested and rendered the 
resource)
* Uses fallback mechanism

UA 3.
* Supports image/png
* Requests resource with default Accept header
* Server returns image.gif as "image/gif"
* Does not support image/gif, cannot render image
* Uses fallback mechanism

-- Problems --
* UA 1 successfully requested and rendered the image without error
* Both UA 1 and UA 2 could render the image
* UA 3 requested the resource, but could not render the image

-- Author --
* The author will see the image load without error
* The author believes there is no problem with the document


**-- Prescriptive Type Attribute --**

  All UAs build their request based upon the intersection of the listed 
type(s) and their individual supported types.

UA 1.
* Supports image/png (and image/gif)
* Requests resource with header:
    GET /image HTTP/1.1
    Accept: image/png
* Server returns 406 response.
* Uses fallback mechanism

UA 2.
* Does not support image/png
* Cannot request resource
* Uses fallback mechanism

UA 3.
* Supports image/png
* Requests resource with header:
    GET /image HTTP/1.1
    Accept: image/png
* Server returns 406 response.
* Uses fallback mechanism

-- Problems --
* No UA successfully requested or rendered the image

-- Author --
* Author sees a problem, and hopefully fixes it.

-- Without HTTP/1.1 (or similar) Content Negotiation --
* UA 1 and UA 3 will request the image
* Server returns image.gif as "image/gif"
* UA 1 will refuse to render the image
* UA 3 cannot render image


**-- Descriptive Type Attribute --**

  Just like 'prescriptive', all UAs build their request based upon the 
intersection of the listed type(s) and their individual supported types.
  Just like 'advisory', if the resource returned does not match the type 
specified, the UA will still attempt to process the content.
  Thus, this type attribute is best illustrated without HTTP/1.1 content 
negotiation

UA 1.
* Supports image/png (and image/gif)
* Requests resource
* Server returns image.gif as "image/gif"
* Supports image/gif and renders the image
* Should indicate error

UA 2.
* Does not support image/png
* Cannot request resource

UA 3.
* Supports image/png
* Requests resource
* Server returns image.gif as "image/gif"
* Does not support image/gif, cannot render image
* Should indicate error

-- Problems --
* UA 2 does not request the resource
* UA 3 requests the resource, cannot render image and indicates error

* UA 1 Renders image and indicates error
  (that's a useful problem)

-- Author --
* Author sees a error indicated by UA 1
* Author is informed about how to fix the error
* If HTTP/1.1 Content Negotiation was used, the UA should also indicate 
the 406 response error

  For all cases, after correcting the error, UA 1 and UA 2 will 
successfully request "image/gif" and recieve and render the image.  UA 3 
doesn't support image/gif, so no request will be made.

  I really hope this clears up any misunderstandings from my previous 
posts.  I have taken a lot of care to ensure that everything I've 
written is correct, however, I'm not perfect and still may have made 
some mistakes.

CYA
...Lachy!

Received on Wednesday, 19 November 2003 09:29:09 UTC