Subject: Re: [Ltru] xml:lang syntax

From: "Doug Ewell" <[email-masked]>
Date: Fri, 9 May 2008 18:58:40 -0600

Leif Halvard Silli <lhs at malform dot no> wrote:

>> I think this would be bad. Lists of language (asserting the language 
>> of a span of content) make processing, parsing, validation, and other 
>> operations harder. They make it harder for users to tag content, 
>> since users have to think of potentially more than one tag.
>
> That it may be illegal with more thane one tag does not mean that 
> tools and users must not know about more than one tag in order to 
> understand what that single tag means.
>
> You must for intance know that 'zh' covers 'yum' and vice versa.

This is a non sequitur.  "Knowing about" more than one tag in the sense 
of matching macrolanguages has nothing to do with a protocol accepting a 
list of tags where it has previously allowed only one.

> You must try to figure out what "mul" covers.

Wrong.  Nobody is ever required to figure out what the infinitely vague 
"mul" covers.

>>  This idea that an item is in "multiple languages" is mostly wrong.
>
> If it is only "mostly wrong", then it isn't wrong.

This is interesting logic.  But I had the same concern as Addison: what 
practical use is it to state that content is in multiple languages, 
without specifying which parts of the content are in which languages?

> For instance "mul,en,fr" is a list which says the same thing, becuse 
> "en" is encompassed in "mul, as is "fr". Likewise "zh,yum,cmn" is a 
> list of the same thing because 'yum' and cmn' ar contained in 'zh'. 
> "no,nn" is a list of the same thing."

That's exactly why "mul" is useless -- by definition, it covers 
everything.  It would be like addressing a letter with "Milky Way 
Galaxy" at the bottom.

I am categorically opposed to adding anything to RFC 4646bis (or the 
postulated RFC 4647bis) that expands or further sanctions the use of 
"mul" in any way.  Considering how bold this group and ietf-languages 
have become about judging and interpreting language usage beyond what 
ISO 639 specifies, I would no longer be opposed to deprecating "mul" and 
"mis" if the topic came up.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Sat, 10 May 2008 03:54:02 +0200

> list of tags where it has previously allowed only one.

I did not speak about "matching macrolanguages". I spoke about the 
opposite - telling which emcompassed language that is meant.  And it 
would be a protocol issue. It is not for us to solve.

> Wrong.  Nobody is ever required to figure out what the infinitely vague 

No one are required to find out what 'zh' means either, then. And not 
'no' and not 'ar'.

> This is interesting logic.  

Either there is a usecase or there isn't.

> But I had the same concern as Addison: what 

Perhaps I don't want to tell you in which language you should read this 
number: <span lang="mul">123</span>.

Perhaps I want to tag something as multilingual.

Usually, in HTML/XML, what the element start tag says is true about the 
entire element. So if you want to spesificly tag the element as 
multilingual, you can do that  with 'mul'.

> everything.  It would be like addressing a letter with "Milky Way 

It does not cover everyting. It covers "multiple languages".

> "mul" in any way. [...]

What we have discussed here  - lately at least - is how a protocol - XML 
- could allow several tags. Not how 'mul' could be extended.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Sat, 10 May 2008 05:22:37 +0200

> would be a protocol issue. It is not for us to solve.

Given Debbie's last message about matching from 'ar' to 'arb' to 'arq' 
etc: the matching problem is of course "for us to solve" - as far as it 
is possible.
-- 
leif halvard silli