- From: Ernest Cline <ernestcline@mindspring.com>
- Date: Sun, 23 Nov 2003 22:00:44 -0500
- To: "Oskar Welzl" <oskar.welzl@pan.at>, www-html@w3.org
- Cc: "Christian Wolfgang Hujer" <Christian.Hujer@itcqis.com>
> [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.)
Received on Monday, 24 November 2003 12:36:39 UTC