W3C home > Mailing lists > Public > www-html@w3.org > November 2003

AW: AW: AW: XHTML 2.0 and hreflang

From: Oskar Welzl <oskar.welzl@pan.at>
Date: Tue, 18 Nov 2003 21:23:09 +0100
To: <www-html@w3.org>
Cc: "Christian Wolfgang Hujer" <Christian.Hujer@itcqis.com>
Message-ID: <000901c3ae11$c8380f20$0100a8c0@mshome.net>
Christian,


> > he can't always be. XHTML can't assume the author knows 
> anything about the
> > protocol that will be used! example: i write a presentation (10 XHTML
> > documents, 1 table of contents, relative URIs for the links) 
> and upload it
> > to my private webspace. my boss burns it on CD-ROM to have it available
> > when travelling. later she'll put it on an FTP server.
> And how will an extended redefinition of @hreflang affect that?

@hreflang will affect it once i start using it:
using @hreflang the way you suggest, and given the proper server configuration, i might use @hreflang to link from the table of contents to some href="chapter1" , telling the server with @hreflang that it should deliver the german version, "chapter1.de.htm" or whatever its name is.
i can safely do so once XHTML 2.0 contains the attribute and defines it the way you suggested. if can, later on, safely forget that my originally planned english translation of "chapter1" is still part of the document collection, because @hreflang="de" will force the UA to retrieve the german version, anyway. which is fine, because that's what i intended.

my boss, though, when burning the whole collection of documents on CD-ROM, will run into troubles. she will no longer be able to open chapter1 because the browser has no way to tell that href="chapter1" was originally meant to retrieve "chapter1.de.htm".
my boss will either get nothing or a file named "chapter1" (should it exist), which could be anything but is certainly not the document that was intended.

that's how a changed definition of @hreflang will change it.

> Hey, we should decide wether we
> a) keep on talking about my example or
> b) keep on talking about the general case, just giving examples where
> appropriate

i've never talked about your special example. 
i'm sorry if i gave the impression i did.

as i'm interested in XHTML 2.0 as a sturdy, portable document markup language (and not in one of its many possible uses), i discuss the general case and try to find examples where necessary. 

> b) Just because there's a @hreflang attribute in XHTML doesn't 
> neccessarily
> mean that all authors use it and create documents that can't be 
> easily copied
> to a different server. Just because a feature someone might use might not
> work in some situations doesn't mean the feature is bad and mustn't be
> implemented.

it's not the enhanced feature (content negotiation) that doesn't work in some situations.
as shown above, it's the whole link that will no longer work becaue the hreflang-value becomes part of what identifies the linked document.

> > > That can't be an argument against my @hreflang suggestion.
> > > Noone's forced to use @type and @hreflang for content
> > > negotiation. It's an
> > > option.
> > once the draft says that the UA "must" (!!), it's no longer an option.
> That's something else. But weren't we talking of the author in the first
> place?

sorry, misunderstanding:
i think you meant "no one needs to use @hreflang (which, if you use it, will initiate content negotiation)"
i understood "if @hreflang is present, no one needs to use it for content negotiation (they can still go on and use it as metainformation only)"

> > we
> > are forced to live with content negotiation and the resulting browser
> > incompatibilities when handling protocols other than HTTP then. 
> and right
> > now, the draft does say "must".
> Right now the draft (if you're talking of the XHTML 2.0 draft) 
> says nothing
> about @hreflang.

Ernest introduced @type to the thread some days ago. the issue is the same.


> Giving a single argument to @hreflang doesn't work so much 
> different from the
> way it does now. Well, currently, @hreflang absolutely does nothing. 

that's basically the same with all meta information. meta information doesn't *do* anything. it's there to tell you things if you ask for them specifically.
you want @hreflang to be a part of the logical URI: the linked document will be identified by a combination of @hreflang and @href, depending on HTTP mechanisms. that's not meta information any longer from my point of view. it's information vital to reach the linked document - provided there's something on the other end that speaks HTTP.

> So even if you use it: If you used it correctly, and the server 
> isn't faulty
> configured, an extension in the definition of @hreflang shouldn't 
> affect you.

it affects me in that i can no longer copy documents from a webserver to CD-ROM in case the author used hreflang="de, en, fr, tr"


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


regards,
oskar







regards,
oskar
Received on Tuesday, 18 November 2003 15:21:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:40:10 UTC