AW: AW: AW: AW: XHTML 2.0 and hreflang

Christian,

> Sorry if I don't agree.

i never expected you would ;-)

> The source of the problem you describe is not the @hreflang in 
> particular but 
> the use content negotiation in general.
> The problem can also occur when not using @hreflang but when 
> burning a site 
> consisting of negotiating html/xhtml docs with negotiating uris on cdrom.
> 
> The trouble is not caused by the @hreflang attribute, it is caused by the 
> negotiating URI. And using negotiating URIs is possible 
> independantly of how 
> @hreflang is defined.

there's a difference, though:
with a @hreflang not influencing content negotiation, it's plain for the author that he has two choices: identify the exact file he wants ("start.de.htm") or live with the fact that "start" will be whatever language client and server negotiate is most suitable. if in this situation the author decides to use a negotiating URI - well, so be it.
on the other hand, with @hreflang influencing content negotiation, the author (as in many of our previous examples) might point to a negotiating URI *and* identify one single document to be retrieved by @hreflang. 
what we'd build into XHTML with this kind of behaviour is the invitation to split what used to be one portable, protocol-independent, easy to manipulate URI into two attribute values that have the same meaning, but give the expected result only in a language negotiating environment, thus sacrificing portability, protocol-independence and ease of manipulation.

i would even see a benefit in this if @hreflang *needed* to be multi-valued and all existing protocols would allow to negotiate content. this would allow for a third way: 
1) is specifying a single file, 
2) is gving the negotiating URI only and 
3) would be to give a negotioating URI but disable some unwanted languages by listing only those desired in @hreflang. (a @hreflang with a single value is equivalent to a single file and therefore should not be used then.)
however, as most protocols will not allow you to negotiate, this benefit is lost. 

> I want @hreflang and @type to be not just meta information.

yes, that's where our opinions differ. 

> The problem I see there now is that if XHTML 2.0 should support 
> @hreflang and 
> @type, the behaviour for non-HTTP URIs should be well defined at 
> least for 
> such operating environments that provide meta information like 
> the mime type, 
> but such a specification is beyond the scope of XHTML 2.0 and 
> concerns URI 
> and content negotiation in general independently of XHTML 2.0 or HTTP.


finally we agree. get the champagne.
the idea is simply beyond the scope of XHTML.
if it was some scripting language for web-applications, not XHTML, it would be great. it would then make sense to specify thing so closely related to HTTP.

> If @hreflang keeps to be just meta informational, hreflang="de, 
> en, fr, tr" 
> could be ambigous: A document is available in 4 variants or the document 
> contains four languages... - not a bad ambigouty at all.

as i said at the very beginning, with @hreflang being meta-information only, i'd much prefer it to have one value only. i think listing multiple values in one attribute is not good XML. it complicates further generic processing (XSL-transformations etc.) by applications not aware of the XHTML syntax.

> > > Okay, maybe you know a better solution for my original problem:
> > > A document exists in the following choices:
> > > start.de.xhtml
> > > start.de.xhtml.gz
> > > start.de.html
> > > start.de.html.gz
> > > start.en.xhtml
> > > start.en.xhtml.gz
> > > start.en.html
> > > start.en.html.gz
> > > The user agent is configured to send Accept-Language: en
> > > The user follows a link labelled "Homepage (German / Deutsch)".
> > > The request sent is something like this:
> > > GET /start HTTP/1.1
> > > Accept-Language: en
> > > Accept: text/html
> > > Accept-Encoding: x-gzip
> > >
> > > And the result is:
> > > HTTP/1.1 406 Multiple Choices
> > > ...
> > >
> > > instead of
> > > HTTP/1.1 200 OK
> > > Location: /start.de.html.gz
> >
> > sure: if the text in your link tells the user it will retrieve 
> a compressed
> > version of the german start-page, make href point to "start.de.html.gz".
> > KISS.
> That's not a solution to the problem, you know that ;-)

in fact, i think it is. (although i admit i enjoyed being a bit provocative *g*.)
i know it's not what you *want*, but let's face it:
negotiation should take place between the client and the server, based on the capabilities of the two systems.
you will have to rely upon negotiation if there's no other way to determine which content to serve.
however, if the author of a document clearly states (as in your example) that by following the link, one should see the *german* version of the document - what is there to negotiate? you want the german verion, you get it. 


regards,
oskar

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