Re: Type Attribute

Hi,
  Firstly, I apologize for making this long, I attempted to cut 
everything that was not necessary, but could not cut any more.  (Please 
just remember, that this was originally twice as long)  However, I have 
broken this into clearly defined sections for easier reading and 
understandig.


  -- Introduction --

  From what I can understand from all the posts in this thread, that I 
have read, there seems to be several separate questions that are being 
addressed, although generally they have been mixed together.
1. Should the type attribute be prescriptive or advisory?
2. Should @type be a single- or multi-valued attribute?
3. Should q-values be allowed within @type?
(These will be referred to as 'question #')

Assuming there is no reason to have q-values when there is only a single 
value, this gives six options:
1. advisory and single-value <= HTML 4 version
2. advisory and multi-value without q-values
3. advisory and multi-value with q-values
4. prescriptive and single-value
5. prescriptive and multi-value without q-values
6. prescriptive and multi-value with q-values <= Current XHTML 2.0 version
(These will be referred to as 'option #')


  -- Definitions --

Advisory: Giving advice, or information, about what content-type(s) 
is/are available.  The UA may then continue to take action based on this 
advice in any way.  Depending on the protocol in use, or any other 
factors the UA takes into consideration, the UA may request only those 
types advised of, and/or only those types that can be supported.
  The action taken upon receiving the requested resource is indifferent, 
regardless of whether that actual type delivered was listed or not.

Prescriptive: Laying down rules about which type(s) is/are available and 
which type(s) can be requested.  The UA MUST build its request from the 
intersection of those type(s) advised of and those types that can be 
supported.
  The action taken will depend on whether the actual content-type 
received was listed in the type attribute or not.

NOTE: 'The action taken...' refers to whether or not
      the resource is processed, regardless of what
      the content-type of the resource is; and whether
      or not the content can be understood.  In the
      cases where the content is not understood, the
      action taken will be the fallback mechanism.

  Whether the attribute is prescriptive or advisory, it is still 
providing advice about what type(s) is/are available.  Therefore a 
prescriptive attribute is still advisory, but an advisory attribute is 
not necessarily prescriptive.

Ernest Cline wrote:

> 1) The type attribute is not needed for resources retrieved using
> HTTP or other protocols that provide a mechanism to indicate
> the MIME type(s) of the resource.

Clarification: The type attribute is not needed for determining the 
content type after the response, and the requested resource is received. 
It is still still useful for determining content prior to sending the 
request and receiving the response regardless of the protocol.


  -- Question 1: "Should the type attribute be prescriptive or advisory?" --

> * Why should we want an advisory type attribute?
> To provide a way for the UA to offer a choice to the user of formats.

  The only factor affecting the ability of a choice is whether @type is 
single- or multi-valued, not advisory or prescriptive.

Pros of Advisory:
1. Informs the UA of what is available
2. Enables the UA to load a resource based on whether or not the type is 
supported (or wanted).
3. Allows the UA to process the received resource based on what is 
actually received, and not what was listed.

Cons of Advisory:
1. Places no real restriction on what types should be requested or 
delivered.

> * Why should we want a prescriptive type attribute?

  As previously stated, a prescriptive attribute is still advisory.  
Thus Advisory Pros 1 and 2 also apply to prescriptive.

Pros of Prescriptive:
1. Clearly defines what is available and what should be requested 
(opposite of Advisory Con 1)

Cons of Prescriptive:
2. Forces the UA to only process the resource if the type was listed in 
@type. (opposite of Advisory Pro 3)

> ...What if a resource is not of the type it says it is?...
> There are four options I can see occurring here.
> ...
> 4) <snip/> (Determines type by inspection, processes resource if it 
> can, else process fallback.  error message is optional.)

  Version 4. is the only option that really needs to be considered since 
it covers every other version.

> ...it is possible that a resource could be validly interpreted as any 
> of several MIME types... expect user agents to make every attempt to 
> resolve the "problem"...
> ...option 4 gives the user agent the same behaviour once the resource 
> has been retrieved, regardless of whether a type attribute has been 
> specified...

  Absolutely Agree!

  -- Conclusion to Question 1 --

  IMO, we want a solution that has both the pros of advisory and 
prescriptive, and without the cons of either.  Based on this, I will 
introduce and define a new term for the kind of attribute that I think 
type should be:

Descriptive:  Gives a description of the type(s) that is/are available.  
The UA SHOULD build its request from the intersection of those type(s) 
advised of, and those types that can be supported.
  The action taken upon receiving the requested resource is indifferent, 
regardless of whether that actual type delivered was listed or not.

(If someone can think of a better term than 'descriptive', it would be 
greatly appreciated, though I think descriptive is quite good for now)


  -- Question 2: "Should @type be a single- or multi-valued attribute?" --

> <span type="text/x-format1,text/x-format2" src="example.txt">
> </span>

(I will refer to that as 'example 1')

> example.txt meets the requirements to fit either MIME type
> and that the user agent has different methods of presenting both types.
> Which is to be preferred?...
> * q-values are specific to HTTP and thus not suitable for generic use.

(see the section relating to question 3 for a response to this)

> ...
> * Position can already be handled via:
> <span type="text/x-format1" src="example.txt">
> <span type="text/x-format2" src="example.txt">
> </span>
> </span>

(I will refer to that as 'example 2')
  Ignoring the possibility of q-values, if the order of the 
content-types was taken into account, then example 1 and example 2 are 
equivalent.

> While the brevity of the first form is desirable, how often is such
> a case really going to occur?...

  I'll use a real world example here:
In XHTML 1.1
<img src="valid-xhtml11" alt="Valid XHTML 1.1!" 
style="width:88px;height:31px" />
(This returns either valid-xhtml11.png  or valid-xhtml11.gif)

In XHTML 2.0, this will translate to either:
a. (With multi-valued type)
<span src="valid-xhtml2" style="width:88px;height:31px"
      type="image/png, image/gif">Valid XHTML 2.0!</span>

b. (With single-valued type)
<span src="valid-xhtml2" style="width:88px;height:31px" type="image/png">
    <span src="valid-xhtml2" style="width:88px;height:31px" 
type="image/gif">
        Valid XHTML 2.0!
    </span>
</span>

  Version a. allows the user or UA to have a choice of receiving gif 
rather than png (or vice versa) when available.
  Version b., however, always accepts png if png is supported, without 
any choice.  Thus, having the single-value attribute is more 
prescriptive in this case.

  -- Conclusion to Question 2 --

  Since, IMO, a single valued attribute appears to be more prescriptive 
than advisory, I believe a multi-valued attribute should be used.


  -- Question 3: "Should q-values be allowed within @type?" --

  This question is only relevant if multiple types are allowable within 
the attribute.

> * q-values are specific to HTTP and thus not suitable for generic use.

  q-values are inherited from HTTP, however, this does not mean that 
they cannot be used for informing the UA about the preference of 
content-types in the general case.
  I do not understand enough about q-values to really comment on these, 
so I will leave this discussion to those of you who do.


  -- Conclusion --

  IMO, we should have a type attribute that fits between Option 1 and 
Option 6 (from the beginning of the message)
  A 'Descriptive' type attribute combines the pros of both prescriptive 
and advisory, without the cons.
  I believe a mult-valued type attribute is less prescriptive and more 
descriptive than a single-valued attribute
  As I already stated, I am not too sure about q-values.

This gives us the following revised options:
1. Descriptive and multi-valued without q-values
2. Descriptive and multi-valued with q-values

CYA
...Lachy

Received on Monday, 17 November 2003 23:54:29 UTC