Re: AW: AW: XHTML 2.0 and hreflang

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

Hi Oskar,

Am Montag, 17. November 2003 22:42 schrieb Oskar Welzl:
> Christian,
>
> > > > > Christian, if a german version of 'glossary' wouldn't exist, it
> > > >
> > > > would be a
> > > >
> > > > > bad practice for the author of the linking document
> >
> > (star.de) to link
> >
> > > > > to it, wouldn't it?
> > > >
> > > > Why should it be bad practice? In some cases it might be bad
> > > > practice, but in
> > > > other cases it might be quite okay.
> > >
> > > I can't see any case in which intentionally creating a broken
> >
> > link is not
> >
> > > bad practice.
> >
> > But linking to an English glossary from a German page isn't a broken
> > link.
>
> the point of your original example was that the user would get the english
> version if the german (to which the link pointed) wouldn't exist. you
> basically constructed a link from a german page to a german glossary with a
> fallback to the english glossary. that's what i call a broken link: linking
> to a german glossary that's not there. presenting the user the english
> version instead might seem elegant from a technical point of view. speaking
> usability, a well designed error message would be better. (you should give
> the user what he expects or a clear error message, but never something he
> didn't want and didn't expect.)
A text on the page could say "Some information is available in English only".
I'm not talking of theory but of my experiences with multi language sites and
content negotiation.


> > > you assume that
> > > - the linked resource is a document
> > > - the protocol is http
> > > - the author of the linking resource is in control of the protocol to
> > > be used (http or other)
> >
> > Yes. He always should be.
>
> 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?

> > > - the author of the linked resource is in control of
> > > the server and its configuration
> >
> > Yes. At least Options +MultiViews, AddType and AddLanguage or similar in
> > Apache httpd.
> >
> > > - different language versions of a
> > > document are intended to be simple translations, meaning that the
> > > samecontent is presented without change in another language
> > > none of this can be safely assumed.
> >
> > It can be, because it's all the same author.
>
> why should it be the same author? all XHTML documents will be created by
> the same author? am i missing something?
> is there a secret chapter 0 "all your author are belong to us" in the
> draft?
Not neccessarily, but in my case.

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

but if we continue discussion like this, spiked with all these accuses like
"but in your previous example" we'll never get to the point, dear!


> > That's always a problem.
> > See PHP, Perl, CGIs, SSI, JSP etc..
>
> ... and that's PHP's, Perl's, CGI's.... problem. i'd be happy to keep it
> that way and don't want to make it XHTML's problem. XHTML is a document
> markup language and needn't duplicate all the existing troubles in web
> services.
a) at least if switching from one web server to another, the author can assume
there's HTTP.
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.

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

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

> > Again, noone's forced to use @hreflang and @type. It's an option
> > to make more
> > use of the existing HTTP RFCs' features.
>
> pardon me, but that's wrong.
> if we were discussing @httplang and @httptype here, i'd still not agree
> with mixing XTML and HTTP, but i'd definitely care less.

> the problem is
> that both @type and @hreflang are present in HTML 4.01 (and therefore in
> XHTML 1.0), both with a meaning very different from what you propose for
> @hreflang now and what's already proposed for @type in the XHTML 2.0 draft.
Oh, great, very traditional, eh?
To me that sounds nearly like "Oh, href has always be only with a and link
elements, so we shouldn't change that".


> so although you're right in saying that nobody will be forced to use those
> HTTP-dependant attributes, you neglect the fact that by re-defining them,
> you prevent me from using them the way they are, the way i think they are
> useful now.
Giving a single argument to @hreflang doesn't work so much different from the
way it does now. Well, currently, @hreflang absolutely does nothing. It's
metainformation only reflected in Mozilla's context menu and used by some
XSLT transformations or some very few intelligent analysis tools like our
forthcoming web site quality assurance tool. But normal user agents do not
use @hreflang at all and not really many people are aware that this attribute
exists at all.
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.

I really can't see any disadvantages of the new variant compared with the old
variant.


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

Just because there's no possibility for the author to override or extend the 
user's user agent's Accept-Language setting.



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/uVypzu6h7O/MKZkRAq5SAKDVIyQpxJQfS36OCnRDk9Ex40aEygCfZgVk
jEElENfTh02UtwwVFo1KyyU=
=pmx8
-----END PGP SIGNATURE-----

Received on Monday, 17 November 2003 18:43:32 UTC