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