> [Original Message]
> From: Oskar Welzl <oskar.welzl@pan.at>
>
> Ernest,
>
> > > > If @hreflang keeps to be just meta informational, 
> > > > hreflang="de, en, fr, tr" could be ambiguous: A document is
> > > > available in 4 variants or the document contains four
> > > > languages... - not a bad ambiguity at all.
> > >
> > > as i said at the very beginning, with @hreflang being
> > > meta-information only, I'd much prefer it to have one value
> > > only. i think listing multiple values in one attribute is not
> > > good XML. it complicates further generic processing
> > > (XSL-transformations etc.) by applications not aware of
> > > the  XHTML syntax.
> > 
> > I'll have to disagree with both of you here.  Suppose a document were
> > available in English, German, and a bilingual version.  It would be
useful
> > to be able to specify hreflang ="de,en" and have it mean that the
resource
> > is supposed to be the bilingual document. If the intent is supposed to
be
> > any of the three possibilities, then we would need something like
> > hreflang="de en de,en".  However, as I have stated previously, because
> > metainfo attributes like hreflang are most useful for non-negotiating
> > protocols such as FTP that do not provide any metainfo, I am strongly
> > in favor of making them all single valued.  However, in this case, the
> > listing
> > of multiple languages IS a single value indicating that all the
languages
> > occur in the resource, not that versions in each language exist.
>
> I do see your point here, and actually i stated in one of my very first
mails
> concerning this issue that there were situations in the past when I wished
> Ii'd had the possibility to express multiple languages with @hreflang.
> still, from an XML point of view, i think the multi value solution would
be
> wrong. we would repeat the same mistake that was made with SVG's
> @points. it looks like XML, but it isn't. if distinct values can't be
identified
> by corresponding tags/attributes but need to be extracted by some sort
> of string manipulation (try something like "get the third point that has
an
> X-value greater than 100" with an SVG-document), then we betray the
> idea behind XML. so i'd say: if multiple values seem so important, we
> should discuss the possibility of doing something roughly like
> <a href=...>
>   <hreflang>en</hreflang>
>   <hreflang>de</hreflang>
>   multi-language-link
> </a>
> if this turns out to be too clumsy, live with the fact that we can't
address
> the issue of multi-language documents.

I see your point, but with languages, there is already a need for some
degree of value manipulation needed if for example one wants a
search for "de" to also match "de-AT"  However, the rules for a value
of multiple languages could be strengthened by for example banning
whitespace so that for example hreflang="de, en" would be an illegal
value, and by insisting that multiple languages be listed in order so
that hreflang="en,de" would be wrong and only hreflang="de,en" would
be correct for referting to a bilingual English and German resource.
Applying these rules would mean that for multiple language resources
there would be only a single correct way of indicating the value intended.
This would ensure that for each value, only a single representation
would be valid while not significantly adding to the complexity of a
search for any hreflang attribute that has any reference to German.

(Limiting hreflang to values of only a single language such a search
 could for example use the ECMAScript regular expression
 /^de(-|$)/i to search or German hreflang values while allowing multiple
languages per value would require /(^|,)de(-|,|$)/i  I'll grant that the
second regular expression is more  complicated, but it introduces
no problems that the first one doesn't.)