AW: 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.
>
> 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.)

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

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

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

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

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


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

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. 

regards,
oskar

Received on Monday, 17 November 2003 16:41:42 UTC