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

Hello Oskar, dear list members,


Am Freitag, 14. November 2003 22:21 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.

> i do understand meanwhile that you have a very special situation in mind.
> you want some solution tailored for this situation, and you hope @hreflang
> could be it. i still believe, though, that you make a lot of assumptions
> without even knowing.
>
> you assume that
> - the linked resource is a document
No.

> - the protocol is http
Yes.

> - the author of the linking resource is in control of the protocol to be
> used (http or other)
Yes. He always should be.

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

> none of this can be safely assumed.
It can be, because it's all the same author.


> A) an author changes his provider and simply copies the whole directory
> structure from server 1 to server 2. unfortunately, for what reason ever,
> the new provider doesn't care about language negotiation, the author can't
> change the server's configuration. this would force him an all those who
> link to his documents to re-write their code.
That's always a problem.
See PHP, Perl, CGIs, SSI, JSP etc..
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.


> B) you link to a fragment of a german document. the fragment is a citation
> of an english song, english, therefore. @hreflang="en", because @hreflang
> is about the natural language used in whatever @href points to, not the
> language of some containing document that is of no relevance to the link.
That's a very good point which I have to think about indeed.

> C) make example B) even worse by saying that there is an english language
> version of the document that, for some reason, doeas *not* contain the
> fragment in question, maybe because the author assumes that english
> speaking readers know the words of the song anyway. if the user agent uses
> @hreflang to negotiate the language of the retrieved document, the user
> will never see the words of the song you wanted to link to: your link says
> @hreflang="en" because you point to en english resource (within a german do
> cument); the UA would get the english version of the document instead - and
> never finds the fragment identified by your @href
Well that's bad luck and very very special.
But still, B) is a good and valid argument.

> D) a company stores information as XHTML in the local file system. @href
> values are relative URIs. when at work, employees access these documents
> through the file system because this makes it easier to edit them if
> necessary. customers use http and the documents are served by a web server.
> links built upon the @href/@hreflang-combination proposed by you will work
> when accessed via http. employees at work would have to create separate
> versions of the documents without using @hreflang because the file syste m
> doesn't support language negotiation.
That's always a problem with negotiated docs. See PHP, SSI, Perl, JSP, CGI 
etc., so I do not consider this argument to be valid against @hreflang.

> XHTML should IMHO be a document format independent of http. it is used on
> CD-ROMs to access files though the local file system, it is used to link to
> (multilingual) telnet resources, it is used to link to text-documents on
> FTP-servers. in all these situations, @hreflang as a descriptive attribute
> can be safely used. making it proscriptive would mean to tightly bind XHTML
> 2.0 to http and to prevent interlinked collections of documents to be moved
> from web servers do CDs to FTP-servers without changes.....
>
> it is this very reason that makes me believe the proposed @type in the
> current working draft's is wrong. it should be descriptive and one value
> only instead of a list of values.
There we definitely disagree.


> > And it's impossible to use content negotiated language docs with uris
> > containing the language information because if there's no accept language
> > override, the user will often see a 406 response instead of a
> > document that
> > suites him/her, e.g. usually always if he requested a document in
> > a language
> > that doesn't suit his user agent's Accept-Language header.
>
> again: i see you're trying to solve a specific problem.
This problem is specific to HTTP Content Negotiation in general.

> however, from what you tell us here, the problem is about HTTP, not about
> XHTML. i'm not sure if we should use XHTML to solve problems that arise
> from the way HTTP works. i can understand how simple and tempting it seems
> at the first glance - after all, it *is* HTTP that is used with XHTML in
> most cases. still i think we should be more systematic and not cross
> borders here.
But there are places where (X)HTML and HTTP need to interoperate.
I think HTTP Request / Response header relevant items are it. I think the 

Again, noone's forced to use @hreflang and @type. It's an option to make more 
use of the existing HTTP RFCs' features.



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/uIbgzu6h7O/MKZkRAgxmAJ9qD0uInx5nf0Tl61eqdIDCHzJe4QCfRocl
yN4EjD+KMle4vayqeqHKs/A=
=P6H2
-----END PGP SIGNATURE-----