AW: AW: XHTML 2.0 and hreflang and type

Lachlan,

>   I don't understand why you think @type has been made 'proscriptive'?  
> It just doesn't make sense.  Unless you actually meant to write 
> 'prescriptive' which has a completely different meaning, and makes more 
> sense in that context.  However, even if you did mean prescriptive, I 
> still have to disagree.

you're right - i simply repeated Ernest's words without using a dictionary. sorry. of course it was 'prescriptive' i should have used. i'll try to impove my english.

>   In the XHTML 2.0 version, since additional types can be specified, it 
> is still advisory (since it is just advising the UA that more types are 
> available), though it is less restrictive.

i think "advisory" is something different than "descriptive". i'm beginning to learn the difference between proscriptive and prescriptive. don't through other words in now ;-)

you see, the main difference between a descripive HTML 4-@type and the advisory/prescriptive @type in the XHTML 2.0 draft shows when you consider 

<span src="img.gif" type="image/png">hey?! what is it now??</span>

let us assume the image is image/gif, not image/png. the author simply made a mistake.

in HTML 4, it hardly matters. the UA will probably try to fetch the file, anyway, with its default accept-header. no problem.
according to XHTML 2.0 (may 2003 draft), the UA "must" change its accept header to image/png only. (from the draft, 6.6: "The user agent must combine this list it with its own list of acceptable media types by taking the intersection")

this example is to illustrate why the XHTML 2 way of using @type is far from being "advisory" only. it's a firm 'must', not a 'should better' or 'could'.

>   For example, if and image was available in png, gif and jpg format, 
> how could that be using the HTML 4.01 version of @type in XHTML 2.0?
> 
> You could write, as someone suggested previously:
> <p src="image" type="image/png">
>     <p src="image" type="image/gif">
>         <p src="image" type="image/jpg">
>         Image description here...
>         </p>
>     </p>
> </p>
> 

this is a very clear and logical way, not cumbersome at all. i couldn't say anything against it.
keep in mind, though, that the choice of not fetching the png+gif but the jpg will be based only on the @type information, not on the real mimetype of the file.
given the fact that image formats are not necessarily able to present the same content (e.g. animated GIFs, static JPG), the above construct is preferrable to anything else if the author wants to give additional comments for those who see a static JPG instead of an animation ("your browser does not....").

>   But being able to write that in a less cumbersome way, that gives the 
> UA more choice about which type to get is much better, and IMHO, easier 
> (for simplicity, I have excluded the q values):
> <p src="image" type="image/png, image/gif, image/jpg">Image description 
> here...</p>
> 
>   How is this not being advisory?  IMO, it's giving more advice than was 
> previously available in HTML 4.01.

again, the "more advice" is exactly the point. it restricts the behaviour of the UA more than it should by telling it to strip all other values from its accept header. (from the draft, 6.6: "The user agent must combine this list it with its own list of acceptable media types by taking the intersection")

this is not the main point against @type, though.

as i wrote in a previous mail, i think that binding XHTML too closely to HTTP is not a good idea.
yes, XHTML and HTTP are a successful pair, but XHTML is still a general markup language with a wide use, not a part of HTTP.

the current working draft itself points to the problem when stating:
"A user agent should imitate similar behavior when using other methods than HTTP. For instance, when accessing files in a local filestore, <p src="logo" type="image/png, image/jpeg"> might cause the user agent first to look for a file logo.png, and then for logo.jpg."

sounds fine, but what about:
<p src="document" type="application/xhtml+xml, text/html">
what would the user agent do to guess which version of the document is preferred - given you access the file on a LAN via the file system and know nothing about he remote computer where the documents are stored. how should the UA make a "guess"? is it document.xml? document.html? document.htm? ...? all of them are there. two of them may be fetched, the third would be wrong as it contains totally different information.

don't say now that in such a case, the author shoulnd't include this kind of @type in the first place. it might be totally OK because it's a document collection normally served using HTTP. there's just a second way to view them. 


also, "imitate" and "similiar" are not words i would like to find in a technical recommendation when it comes to describe how my application should react to a special situation. the spec should be more specific, which is impossible if it is built upon an HTTP-environment only and simply does not know how to handle others.


regards,
oskar







> [1] http://www.w3.org/TR/html401/struct/links.html#adef-type-A

> 
> CYA
> ...Lachy
> 
>

Received on Saturday, 15 November 2003 11:59:27 UTC