Re: AW: Type Attribute

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

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

>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
>
>"...Based on this advice, the UA may decide whether or not to retrieve the resource..."
>
  That's essentially what I meant by saying: "The UA may then continue 
to take action based on this advice in any way.".  I was just trying to 
be more general with what I said.

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

>>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;
>
  This is where our opinions differ.  Of course the resource being 
requested is in the URI, but the type of resource is expressed in 
@type.  Perhaps, to be clearer, it should have said "Clearly defines 
what is available and what TYPE should be requested" which matches my 
advisory con 1.  Also note that I said "should", not "must", thus 
placing slightly less restriction on the attribute.

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

> <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?
  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?  As I have essentially said before, nesting 
forces the outer most type to be used in preference to any of the 
others.  Also note that this is not an argument against q-values, since 
I don't believe they would be as strict in most cases.

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


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

CYA
...Lachy

Received on Wednesday, 19 November 2003 04:45:32 UTC