AW: XHTML 2.0 and hreflang

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.

> The href attribute points to a language independent canonical 
> base URI, not a 
> document in a certain language.
> Larger multilingual sites are full of links. Currently, no 
> content negotiation 
> is used because based on current possibilities in (X)HTML all possible 
> choices of e.g. document / language combinations have to be 
> handled by the 
> author seperately.

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
- the protocol is http
- the author of the linking resource is in control of the protocol to be used (http or other)
- the author of the linked resource is in control of the server and its configuration
- 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.

consider these situations:

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.

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.

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 document); the UA would get the english version of the document instead - and never finds the fragment identified by your @href

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 system doesn't support language negotiation.


the list of examples could go on forever.
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.


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


regards,
oskar

Received on Friday, 14 November 2003 16:19:49 UTC