AW: AW: Type Attribute

Lachlan,

> >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?)
> >  
> >
> 
>    I'm not quite sure what you mean here, but the resource should be 
> identified by the URI, and @type simply advises the UA what type(s) the 
> resource is available in, and thus allows the UA to decide:
> 1. Whether or not to request the resource; and
> 2. Which types, from the available list, are acceptable, and thus
> 3. Which type to request.
>   If @type is omitted, then of course the UA can still request the 
> resource as they currently do.

your point 3 suggests that it is *not* only the URI that identifies the resource.
example:
you suggest that <... src="valid-xhtml2" type="image/png"> should tell the UA to request "valid-xhtml2.png" instead of "valid-xhtml2.gif" or "valid-xhtml2.jpg" (both of which are available). without type="image/png", it might happen that because of the server configuration, "valid-xhtml2.gif" will be served instead.
therefore, following the "negotiating @type"-suggestion, the resource is *not* identified by the URI and it can *not* be taken for granted that a UA will alsways retrieve the same file, regardless of a @type attribute.
following the "meta-information @type"-suggestion, both <... src="valid-xhtml2" type="image/png"> and <..src="valid-xhtml2"> will *always* retrieve the same file, as it is specified by the URI and only the URI.

> >>  -- 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";
> >  
> >
> Ok, the key to understanding what I meant by saying:
> "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." is in the words I 
> carefully chose.
> 
>   Take note of the words I have added emphasis to.  "may" means that it 
> is completely optional, and the "and/or" means it can do either one or 
> both of them.  Since a UA isn't going to request anything it can't 
> support, I didn't need to say that it could do neither.  The point that 
> I was trying to make, in the shortest and most concise way that I could 
> think of, was that there are options that are left for the UA to decide 
> based on any factors the UA wishes to consider.  Unfortunately, I seem 
> to have sacrificed clarity in favour of shortness.

i think i understood that. it's only that i don't agree.
according to how i interpret HTML 4.01, the user agent 
* MAY use the @type-value to decide whether or not to contact the host and retrieve the resource specified in the URI
* once this decision has been taken, request and accept anything the URI might possibly point to, no matter which value @type had.

so while your may/and/or-construction allows the UA to request either everything it supports or only the mimetype in @type, depending on any factor the UA considers important, HTML 4.01 makes a clear statement on how UA should act. 
thinking in terms of interoperability, browser compatibility, etc., i prefer the more strict definition. 


> >>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. 
> >
>   Because I didn't see any point to an advisory attribute if it doesn't 
> help to determine what to request.

it helps to determine *whether* or not to request before even connecting to the resource. it's not there to determine *what* to request.
and, returning to my "question 4" from the beginning:
*what* to request should be expressed in the URI. that was my point. i don't think meta information is there to supplement ambiguous URIs. 

 
> > i see no benefit in splitting resource identification into two (or 
> > more =>hreflang?) attributes when a URI alone is bad enough.
> 
>   Because a canonical URI cannot express, sufficiently, both the 
> language and the type.  If it could, what would be the point in having 
> either of the attributes?

the point in having the attributes is the same as with all meta information. if we now conclude this thread saying that meta information is unnecessary (because it doesn't affect the visible content), we'd better hope that there's no one out there who shares our opinion.... that would be the end of RDF and all semantic web activity.

> > <span src="valid-xhtml2" style="width:88px;height:31px" 
> > type="image/png">Valid XHTML 2.0!</span>
> 
>   If a single, advisory (HTML4) type attribute is used, and the resource 
> can be either valid-xhtml2.png, valid-xhtml2.gif or even 
> valid-xhtml2.jpg, valid-xhtml2.svg, or any other image type, then what 
> is the point of having the type attribute at all, since it is only 
> descriptive of one of the possible resources?

the same question could be asked for any other variant of @type discussed so far.
we never know if the value given corresponds to what is really sent by the server.
implications are different, but the problem is always there.
the point of having the descriptive attribute is that a UA at least has a chance to decide if its worth contacting the host. if the information in @type is wrong - well, that's the author's fault. but if we want to make XHTML 2.0 foolproof, we'd better start thinking about how we can prevent authors from creating broken links by giving wrong @href-values. that's far more relevant in every day use.

>   I realise that the multiple types could be nested, but what right does 
> the author have to *strictly* enforce a preference of some image types 
> over others, onto a user?  

well ... its him who creates the document, isn't it? if he creates it using GIF instead of JPG, then the user will have to live with it. i wouldn't want users loading the old JPGs into my documents instead of the new animated GIFs i created a few days ago.

> >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)
> 
> Why not?  The multi-value attribute is simply advising of more 
> than one type.  If a user agent can support one or more of the 
> listed types, then it can, and should request the resource.

again you're assuming that the UA will use the type value to create an accept header accordingly.
this is not the case.

> >...@type in the embedding attribute collection (interestingly 
> enough, not the object-attribute with the same name) and in your 
> proposal has two meanings now:
> 
>   Actually, <object> uses the 'Common' collection, which includes 
> the embedding collection.  Why is it also defining its own @data 
> and @type, rather than just using @src and @type from the 
> embedding collection?

i have no idea. the current working drafts lists this as an open issue, so we needn't tell them about it ;-)

regards,
oskar

Received on Saturday, 22 November 2003 16:12:58 UTC