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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Oskar,

Am Dienstag, 18. November 2003 21:23 schrieb Oskar Welzl:
> 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.
Sorry if I don't agree.
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.


> > > > 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)"
Oh. Well, the ambiguity of language...

Of course, if @hreflang would be specified as I propose it, there must be a 
user agent conformance requirement which exactly describes the user agent's 
behaviour regarding the value of @hreflang, the user agent's default value 
for the Accept-Language http header and the computed value for the 
Accept-Language http header.

> > > 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.
That's true.
The only thing that differs between @type and @hreflang that comes into my 
mind now is that the HTTP RFC says "SHOULD ... 406" about @type (resp. 
Accept) but it doesn't say that for @hreflang (resp. Accept-Language).

> > 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.
That's true.
I want @hreflang and @type to be not just meta information.
By the way, at least for @type HTTP isn't neccessarily the only possible 
protocol as long as the underlying system has a MIME Layer like KDE or 
Windows have.
File access could also use negotiation.

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.

> > 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"
Agreed, you can't.
But the problem isn't the @hreflang attribute, it's the negotiating URI, e.g. 
/start instead of /start.de.xhtml.
And negotiating URIs can always and already be used, wether @hreflang provides 
some additional features for the negotiation or not.

I only want the @hreflang attribute to change and be extended to improve the 
situation under certain circumstances where current user agent and server 
behaviour would result in nasty 406 responses instead of 200 responses.

Thoughts which bring myself thinking that perhaps a server side solution to 
that problem could be more appropriate, if it's just the 406 response.

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.

> > 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 ;-)
By the way the example has a mistake, it was intended to be GET /start.de 
HTTP/1.1.
GET /start will correctly result in a 200 OK response. It's the /start.de 
which causes the problem because the Content-Language doesn't fit the 
Accept-Language.


Bye
- -- 
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/up0zzu6h7O/MKZkRAnnZAJ48pHvSDI6tFYYtyFrRnOZSVFyP5ACeLXSp
qPQSVYNQaFQweyPkab7frPc=
=uZmn
-----END PGP SIGNATURE-----

Received on Tuesday, 18 November 2003 20:41:13 UTC