AW: Type Attribute

Lachlan,

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

brilliant work - very systematic. 

>   -- 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 #')

i would like to add a fourth question:
4. should the UA identify a remote resource using only the URI given in @src (@data, @whatsoever), or should it be computed from this URI plus @type. (in other words: if you strip @type from an existing tag, will the UA in any case fetch the same file as before?)


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

i'm not sure, but reading and re-reading the HTML 4.01 spec over and over again, i think it less likely that they had the faintest intention then that a UA might "request only those types advised of";
of course, there's room for misunderstanding here:
what i have in mind is a situation where, say, src="valid-xhtml11" is available in more than one format. my understanding is that by saying "the UA may request only those types advised of" you mean it might explicitely request the PNG instead of the GIF if the @type is "image/png", thus enabling the author to write src="valid-xhtml11" type="image/png" as an equivalent to src="valid-xhtml11.png".
if that is what you mean, i don't think HTML 4.01 is "advisory" the way you define it. my interpretation always was that HTML 4.01 didn't even take into consideration the possibility that the UA might use @type for any other decision "than should i - or should i not - ask the server for that file". afer all, it explicitely defines what would happen if the HTTP content-type returned by the server differs from @type, so the authors did think about HTTP-implications, they didn't just leave the topic aside. still, they never mentioned anything on the UA's side. that's why i guess they didn't want @type to change the way the UA asks for the file. in the example above (src="valid-xhtml11" type="image/png"), that would mean that a UA might still receive valid-xhtml11.gif instead of valid-xhtml11.png in HTML 4.01.
if advisory/single-value was meant to be the equivalent to HTML 4.01 in this document, we'd have to re-define "advisory" as

"Giving advice, or information, about what content-type(s) 
is/are available. Based on this advice, the UA may decide 
whether or not to retrieve the resource.
The action taken upon receiving the requested resource is indifferent, 
regardless of whether that actual type delivered was listed or not."


>   -- Question 1: "Should the type attribute be prescriptive or 
> advisory?" --
> 
> 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.

i can't see why this is listed as a 'con'?
it's a very neutral fact, if not even a pro. 

 
> > * 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)
i see this as a con rather than a pro. *what* should be requested should be expressed in the URI; having @type interact with the URI, the server configuration and the UA's supported mime types results in an awful triangle of possible problems.
right now, the only thing that can change is the URI - bad enough, broken link. shouldn't happen.
if @type comes in and is prescriptive, additional factors come into play: the URI might remain the same, but the filetype might change. if i link to src="valid-xhtml11" type="image/gif" from my website, nothing would happen with an HTML-4.01-advisory @type if at w3c.org they'd delete the gif an favor of a TIFF. with a prescriptive @type, the link would be broken.
i see no benefit in splitting resource identification into two (or more =>hreflang?) attributes when a URI alone is bad enough.

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

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

doesn't solve my main concern of @type becoming a "hidden" part of the URI


>   -- Question 2: "Should @type be a single- or multi-valued attribute?" --
>   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.

in both examples, you again assume that @type will in any way affect the way the UA retreives files from the host.
assuming that, as in HTML 4.01, this is not the case, the results are different:
Version a) tells the UA that the image is either GIF or PNG; no decision can be taken with that information (a user agent supporting GIF, but not PNG wouldn't know whether or not to retrieve the file)
Version b) offers clear information about the resource identified by a URI.

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

again, with an HTML 4.01-style @type in mind, a single valued attribute can be used while a multi valued attribute fails to provide the information needed.

>   -- Conclusion --
> 

Lachlan, your mail helped me a lot in pointing out my concerns about both the XHTML 2.0 @type and the way Christian wants @hreflang to be redefined. it's much clearer for myself now. Most of it comes down to what i added as question 4 at the beginning:
"4. should the UA identify a remote resource using only the URI given in @src (@data, @whatsoever), or should it be computed from this URI plus @type. (in other words: if you strip @type from an existing tag, will the UA in any case fetch the same file as before?)"

i'm trying to be very strict and systematic when it comes to such things. when i define my own tags and attributes, i think of what they are for, what they should do, and in which situations they should still provide useful information in all thinkable, extreme combinations. 

as for XHTML, i tried to identify among others the following roles:
*@href/@src/@data(...):
the attributes that define a resource. (the fact that HTTP allows a single URI to result in different physical files to be returned, depending on the client/server configuration, doesn't change the role of these attributes in XHTML.)
*@type/@hreflang(XHTML1.0 only)(...):
provide meta-information about the resource defined by @href/@src/@data. their content (or even presence) will not in any way affect which file is to be retrieved. 
*@navindex/@accesskey(...):
other information relevant to the presentation/user interface. no connection to the remote resource at all.

i think it's important to keep things apart, to know what each attribute and tag is used for, to keep the roles clearly separated. i'd prefer not to burden attributes that contain meta information with additional meaning while still keeping the meta information there.
@type in the embedding attribute collection (interestingly enough, not the object-attribute with the same name) and in your proposal has two meanings now:
it still is meta information, unchanged from what it was. on the other hand, it is used to identify the exact file to be retrieved if there is a choice; that's basically what href/data/src should be for. once you do this, you can no longer safely omit the meta information as this would change the document's visible content. (and what kind of meta information is this that influences the visible content?)

i'm not happy with this. no, no, i'm not happy with this.


regards,
oskar

Received on Tuesday, 18 November 2003 17:43:56 UTC