Re: Type Attribute

> [Original Message]
> From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>

> 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 useful for determining content prior to sending the 
> request and receiving the response regardless of the protocol.

It is possible via either the OPTIONS or the HEAD method of
HTTP 1.1 to obtain information about the resource without getting
the whole resource.  This has the advantage of ensuring that
information about the resource is as accurate as possible with
the disadvantage of extra overhead.  Because there are
advantages either way for HTTP, I feel that the type attribute
should be tailored to be most responsive to serving the needs
of other protocols.

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

If I'd felt that way, I wouldn't have bothered with the other three.
The critical distinction between option 4 and the others is that
version 4  tries to correct a mistake and fix it.  While this is the
behavior that has been done in the past, the philosophy
behind XHTML2 seems to be that a user agent should not
be expected to make sense of malformed data.

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

Yes they are equivalent in effect, but the former requires
a more complicated user agent.

For user agents that need to worry about their program size,
every little bit helps.

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

Actually, the direct translation would be
c. (With single-valued type using a wildcard)
<span src="valid-xhtml2" style="width:88px;height:31px" type="image/*">
  Valid XHTML 2.0!
</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.

Version c. allows the UA to receive any image format including
png or gif.  While wildcarding can be thought of as a special case
of multivaluing, it does use the single value syntax

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

I agree that a single-valued attribute is more prescriptive.
However that is in part why I prefer it.

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

With HTTP if q-values are part of the type attribute they would have
to be combined with the q-values of the user-agent and the server.
Furthermore, the author could achieve anything he would wish to
achieve with in document q-values by setting them server side.

If on the other hand, q-values are used to indicate preference
in other protocols, that can already be achieved by nesting.
I don't think that minor improvement in ease of XHTML authoring
is worth the complication in deciphering XHTML by a user agent.

My Conclusion:
Using q-values complicates the user agent's task in interpreting
XHTML.  The only use case that I perceive is that it would enable
an author to express a q-value moderated preference without
accessing server settings in HTTP.  That use case is not
compelling enough in my opinon to warrant the complication.

While an argument can be made for allowing multiple types
to be defined, I don't agree with it.  For HTTP, allowing
multiple types is nice but not necessary.  For other protocols
a prescriptive single valued type attribute is clearly the best
alternative.

Received on Tuesday, 18 November 2003 13:02:02 UTC