Subject: [Ltru] Re: ISO 639-2 decision: "mis"

From: Addison Phillips <[email-masked]>
Date: Wed, 13 Jun 2007 16:32:37 -0700

I note that this is what most people probably thought it meant in the
first place. It is the only meaning that makes any sense and I cheer
this clarification.

Yes, the "meaning" of the 'mis' code is "narrowed" by additions of codes
(assuming that codes added alway cover additional languages and not just
finer gradations of existing ones, a case that isn't that uncommon)---if
one takes a collective view of all content in the universe and assigns
it a language tag today.

But the definition of the 'mis' code is exactly what 4646bis is 
currently set to say: stuff whose language is known (not 'und') but 
which you can't otherwise tag, either because no code is available or 
(more likely) the code isn't available to your application.

The reasons for using the 'mis' code are limited and I suspect that we
hardly ever see it in the wild nor will we in the future. As a tag it 
only has meaning in the context of a fixed set of content and it has 
essentially no meaning in language ranges except when working with sets 
that are known to use it.

As for deprecation, I think this is such a perverse interpretation of 
the meaning of "narrows" that I can't see following through on it with 
deprecation. Let's fix our draft text and move along. Currently the 
draft for the next version of BCP 47 informs users why the subtag has 
limited value and say that it SHOULD NOT be used. That's strong enough.

Addison

Mark Davis wrote:
> This is a mixed bag. On the one hand, it is great to finally get some 
> clarity on the intended meaning for the future. On the other hand, it 
> means that this code's meaning is intrinsically intended to narrow over 
> time; as each new code is added, its meaning narrows to cover fewer 
> situations. This is inherently *unstable*, and unsuitable for any 
> situation that demands stability, like BCP 47.
> 
> Note that this still does not allow a narrowing of "mis" in BCP 47. 
> However, for this case I think it makes the case strong enough for 
> completely deprecating "mis" in BCP 47bis.
> 
> Mark
> 
> On 6/13/07, *John Cowan* <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Håvard  Hjulstad scripsit:
> 
>      > The identifier mis, which has been part of ISO 639-2 since its
>      > publication in 1998, has its scope changed from collective to special
>      > purpose.
>      >
>      > The previously assigned "names" in English and French were
>      > "miscellaneous languages" and "diverses, langues". These "names"
>      > have been changed to uncoded languages and langues non codées.
> 
>     Hurrah!
> 
>     --
>     In my last lifetime,                            John Cowan
>     I believed in
>     reincarnation;                    http://www.ccil.org/~cowan
>     in this lifetime,                               [email-masked]
>     <mailto:[email-masked]>
>     I don't.  --Thiagi
>     _______________________________________________
>     Ietf-languages mailing list
>     [email-masked] <mailto:[email-masked]>
>     http://www.alvestrand.no/mailman/listinfo/ietf-languages
> 
> 
> 
> 
> -- 
> Mark
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-languages mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/ietf-languages

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Jun 2007 21:17:21 -0700

Hi -

As a technical contributor...

> From: "Addison Phillips" <[email-masked]>
> To: "Mark Davis" <[email-masked]>
> Cc: <[email-masked]>; "vard Hjulstad" <[email-masked]>; "'LTRU Working Group'" <[email-masked]>; <Hå>
> Sent: Wednesday, June 13, 2007 4:32 PM
> Subject: [Ltru] Re: ISO 639-2 decision: "mis"
...
> (more likely) the code isn't available to your application.

"Because no code is available" is supported by the definition.
Because "the code isn't available to your application" is not, in my opinion.

> limited value and say that it SHOULD NOT be used. That's strong enough.

I could live with this.

Randy

---

From: Peter Constable <[email-masked]>
Date: Sat, 16 Jun 2007 12:56:30 -0700

From: Kent Karlsson [mailto:[email-masked]]

> With the "old mis" one could correctly apply 'mis' as a language
> code for any language

That has *never* been the intent of ISO 639. It is an external interpretation, admittedly possible because ISO 639 was not fully explicit up to now. But from the perspective of the JAC, the "new mis" is exactly the same "mis" as the "old mis".

Peter

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jun 2007 11:03:34 +0200

Peter Constable wrote:

> But from the perspective of the JAC, the "new mis" is exactly the
> same "mis" as the "old mis".

 From the perspective of a registry user seeing only the description
"uncoded" appears to be slightly broader than John's definition
"uncoded and not covered by any other collection".

E.g. "missingsch" is a mixture of nl, nds, and some other languages,
and I think it's "uncoded".  But it should be tagged as "gem", not
"mis".  Maybe the verbose explanation in 4646bis should copy the
verbose JAC-definition, and / or add an example.  Or add a comment
to the bulk registry update (individual registration doesn't work).

Frank

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 18 Jun 2007 10:09:25 -0700

This got bounced for too many recipients: trying again. MD

---------- Forwarded message ----------
From: Mark Davis <[email-masked]>
Date: Jun 18, 2007 9:23 AM
Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"
To: Peter Constable <[email-masked]>
Cc: Kent Karlsson <[email-masked]>, Milicent K Wewerka <
[email-masked]>, John Cowan <[email-masked]>, "[email-masked]" <
[email-masked]>, "[email-masked]" <[email-masked]>, "
[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "
[email-masked]" <[email-masked]>, LTRU Working Group <[email-masked]>

Unfortunately, ISO codes have somewhat of an impedance mismatch with the
needs of the IT community; in particular, stability. Thus BCP 47 has to
stabilize those codes; one of the main reasons for the existence of RFC
4646. What that means is that if ISO tries to narrow the meaning of *any*
code, whether it is a "clarification" or not, we have really only two
choices:

1. Keep the broader semantic, which encompasses the new ISO narrow one, or
2. Deprecate the code (in one way or another).

Unlike many other codes, "mis" is one that we can do without, so #2 was a
reasonable choice.

What I was trying to come up with language that we could agree on even
though we have very different views on the utility and meaning of 'mis'. It
sounds like we are ok on the suggested language on the other thread, so I'm
hoping that we can put "mis" to bed.

Mark

On 6/16/07, Peter Constable <[email-masked] > wrote:
>
> From: Kent Karlsson [mailto: [email-masked]]
>
> That has *never* been the intent of ISO 639. It is an external
> interpretation, admittedly possible because ISO 639 was not fully explicit
> up to now. But from the perspective of the JAC, the "new mis" is exactly the

-- 
Mark

---

From: Peter Constable <[email-masked]>
Date: Mon, 18 Jun 2007 10:17:04 -0700

As far as the JAC is concerned, the intentional semantic of "mis" is what it has always been. As for the extension, when 639-2 was the only alpha-3 code, there was only one context to evaluate the extension that would be derived by that intention; 639-2 did not document the extension, though at least one application of 639-2 - MARC - did. With the introduction of 639-3 and the pending introduction of 639-5 as additions to the alpha-3 space, it becomes clear that the extension must be determined within a context: the cases where you'd want to use "mis" differ if you're using 639-3 rather than 639-2. But for an application of a given part of 639, the change of reference name has had no effect on the extension for that context: the languages encompassed by "mis" in a 639-2 application, for instance, are the same as they were before.

When it comes to BCP 47, the change of reference name for "mis" is basically irrelevant because there is a much bigger issue: in RFC4646bis, BCP 47 will change from being an application of 639-1 and -2 to being an application of 639-1, -2 and -3. That change of context is what creates the issue wrt interoperability of "mis" in applications of BCP 47: Under RFC 4646, Burushaski content would be tagged "mis"; under RFC 4646bis, one would expect new Burushaski content to be tagged "bsk". There's no basis for matching: that's an interop problem. And note that it has nothing to do with stability of "mis" supposedly introduced with the name change: with or without that change, Burushaski content would be tagged differently before and after.

And note that this issue exists whether one considers "old mis" to have the semantic that Keld is stuck on, 'all languages', or the semantic that the JAC has always intended: either way, it is the addition of 639-3 to BCP 47 that creates an issue for uses of "mis" under BCP 47, not the name change.

And even without the addition of 639-3, "mis" would have interop issues: assuming the semantic the JAC has always assumed, the extension in the context of 639-2 could narrow - inherently by the nature of the semantic - any time a new entry was added; but assuming the 'all languages' semantic, one could end up with comparable content tagged in non-comparable ways, "mis" and something else.

Therefore, I suggest that beating up ISO as not being in tune with the needs of the IT community is both fruitless and baseless, and is ignoring the fact that IETF has problems all of its own making. If IETF really wanted to avoid any stability or interop problems related to "mis", it should never have permitted its use in language tags, starting back in RFC 1766, because "mis" has always had stability / interop issues. But that horse is long out of the barn: "mis" *can* be used in language tags under RFCs from 1766 to 4646. The LTRU WG within IETF needs to decide what to do about that in RFC 4646bis. That's a job for IETF; we don't need to continue bothering JAC members with IETF issues.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Monday, June 18, 2007 9:23 AM
To: Peter Constable
Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; LTRU Working Group
Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"

Unfortunately, ISO codes have somewhat of an impedance mismatch with the needs of the IT community; in particular, stability. Thus BCP 47 has to stabilize those codes; one of the main reasons for the existence of RFC 4646. What that means is that if ISO tries to narrow the meaning of *any* code, whether it is a "clarification" or not, we have really only two choices:

Unlike many other codes, "mis" is one that we can do without, so #2 was a reasonable choice.

What I was trying to come up with language that we could agree on even though we have very different views on the utility and meaning of 'mis'. It sounds like we are ok on the suggested language on the other thread, so I'm hoping that we can put "mis" to bed.

Mark
On 6/16/07, Peter Constable <[email-masked] <mailto:[email-masked]> > wrote:
From: Kent Karlsson [mailto: [email-masked]<mailto:[email-masked]>]

Peter

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 18 Jun 2007 09:23:11 -0700

Mark

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 18 Jun 2007 13:49:24 -0700

I really didn't want to start a flame about this; I'm sorry if what I said
was be considered incendiary.

This whole issue is not really connected with the change from part 2 to part
3, at all. Take your example: it is a problem with your definition of "mis"
in BCP 47 whether "brk" were added because of 639-3 OR just because it were
added to ISO 639-2! It is an issue whenever new codes could be added that
would invalidate previous usage of "mis".

And the sad thing is that this instability in ISO codes is completely
avoidable. There is a perfectly good way to have the same functionality
*without* being unstable.

   - Have a code I'll call here "root" (to avoid any misunderstanding
   about the meaning of "mis".)
   - Have it be valid to tag any language content with "root".
   - State that one SHOULD tag as narrowly as possible, thus avoid "root"
   if there is a more specific language code.

This completely takes the place of the need you see for "mis", *without
being unstable*. If I have some Burushaski content, where a code doesn't
exist, I tag it with "root". That is valid now, and remains valid forever,
even once "brk" is added -- whether "brk" were added because of 639-3 or
just because it were added to ISO 639-2.

Mark

On 6/18/07, Peter Constable <[email-masked]> wrote:
>
>  As far as the JAC is concerned, the intentional semantic of "mis" is what
> it has always been. As for the extension, when 639-2 was the only alpha-3
> code, there was only one context to evaluate the extension that would be
> derived by that intention; 639-2 did not document the extension, though at
> least one application of 639-2 – MARC – did. With the introduction of 639-3
> and the pending introduction of 639-5 as additions to the alpha-3 space, it
> becomes clear that the extension must be determined within a context: the
> cases where you'd want to use "mis" differ if you're using 639-3 rather than
> 639-2. But for an application of a given part of 639, the change of
> reference name has had no effect on the extension for that context: the
> languages encompassed by "mis" in a 639-2 application, for instance, are the
> same as they were before.
>
>
>
> When it comes to BCP 47, the change of reference name for "mis" is
> basically irrelevant because there is a much bigger issue: in RFC4646bis,
> BCP 47 will change from being an application of 639-1 and -2 to being an
> application of 639-1, -2 and -3. That change of context is what creates the
> issue wrt interoperability of "mis" in applications of BCP 47: Under RFC
> 4646, Burushaski content would be tagged "mis"; under RFC 4646bis, one would
> expect new Burushaski content to be tagged "bsk". There's no basis for
> matching: that's an interop problem. And note that it has nothing to do with
> stability of "mis" supposedly introduced with the name change: with or
> without that change, Burushaski content would be tagged differently before
> and after.
>
>
>
> And note that this issue exists whether one considers "old mis" to have
> the semantic that Keld is stuck on, 'all languages', or the semantic that
> the JAC has always intended: either way, it is the addition of 639-3 to BCP
> 47 that creates an issue for uses of "mis" under BCP 47, not the name
> change.
>
>
>
> And even without the addition of 639-3, "mis" would have interop issues:
> assuming the semantic the JAC has always assumed, the extension in the
> context of 639-2 could narrow – inherently by the nature of the semantic –
> any time a new entry was added; but assuming the 'all languages' semantic,
> one could end up with comparable content tagged in non-comparable ways,
> "mis" and something else.
>
>
>
> Therefore, I suggest that beating up ISO as not being in tune with the
> needs of the IT community is both fruitless and baseless, and is ignoring
> the fact that IETF has problems all of its own making. If IETF really wanted
> to avoid any stability or interop problems related to "mis", it should never
> have permitted its use in language tags, starting back in RFC 1766, because
> "mis" has always had stability / interop issues. But that horse is long out
> of the barn: "mis" **can** be used in language tags under RFCs from 1766
> to 4646. The LTRU WG within IETF needs to decide what to do about that in
> RFC 4646bis. That's a job for IETF; we don't need to continue bothering JAC
> members with IETF issues.
>
>
>
>
>
> Peter
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Mark Davis
> *Sent:* Monday, June 18, 2007 9:23 AM
> *To:* Peter Constable
> *Cc:* Kent Karlsson; Milicent K Wewerka; John Cowan; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> LTRU Working Group
> *Subject:* Re: (iso639.2708) RE: ISO 639-2 decision: "mis"
>
>
>
> On 6/16/07, *Peter Constable* <[email-masked] > wrote:
>

---

From: John Cowan <[email-masked]>
Date: Mon, 18 Jun 2007 17:19:36 -0400

>   if there is a more specific language code.

If you feel strongly about this, you could ask for it to be registered
as an (exceptional) RFC 4646 language subtag.  "Root" is too short,
but "somelang" would work.

-- 
Take two turkeys, one goose, four               John Cowan
cabbages, but no duck, and mix them             http://www.ccil.org/~cowan
together. After one taste, you'll duck          [email-masked]
soup the rest of your life.
        --Groucho

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jun 2007 23:34:42 +0200

John Cowan wrote:

> "Root" is too short, but "somelang" would work.

It's an idea, maybe "dummy" is a good name.  It should be
combined with scripts, otherwise it's probably pointless.

But it's still very near to "und", why would anybody wish
to make the very subtle point und-Latn vs. dummy-Latn ?

Frank

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 18 Jun 2007 15:00:37 -0700

The main concern I had is deprecating the unstable "mis". I used "root" to
contrast with how it could have been done in a stable fashion. The code
"und" is a superset of "root" -- the basic difference being that "und" can
also include non-linguistic content. So I don't think it is a priority right
now to have a separate code, compared to finishing the other items in
4646bis.

Mark

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 18 Jun 2007 15:02:53 -0700

Bounced again. It's a pain that the recipient limit is so low on LTRU.

---------- Forwarded message ----------
From: Mark Davis <[email-masked]>
Date: Jun 18, 2007 1:49 PM
Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis"
To: Peter Constable <[email-masked]>
Cc: LTRU Working Group <[email-masked]>, "[email-masked]" <
[email-masked]>, "[email-masked]" <[email-masked]>, "
[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Mark

On 6/18/07, Peter Constable <[email-masked]> wrote:

> *From:* [email-masked] [mailto: [email-masked]]
> *On Behalf Of *Mark Davis

-- 
Mark

---

From: Peter Constable <[email-masked]>
Date: Mon, 18 Jun 2007 17:52:31 -0700

Suggesting that 'root' avoids problems is, IMO, rather a bit of false economy. Sure, if a tag means 'some language', then content so tagged never becomes *incorrectly* tagged when an ID for the given language is added. But let's consider whether it is *usefully* tagged: changing things so that it could continue to be *correctly* tagged wouldn't make it more *usefully* tagged, and arguably makes it less so.

To suggest that users needn't worry about their content tagged 'root' after a new language is coded is IMO bad advice. They certainly *should* worry if they want their data to be useful: they'll want to re-tag the relevant content with the newly-coded ID, else they end up with data that won't compare. At least if they know that the addition will narrow the extension and potentially invalidate tagging on some of their content, they're more likely to pay attention; what you suggest can give the impression that they don't have any particular worry, which is not the case.

A tag with the 'root' semantic can always mean anything - which means it's nearly void of meaning and is about as useful as not having tagged it at all in the first place. (The 'root' semantic would be equivalent to 'not zxx'.) That's not *usefully* tagged, but it's vacuously always going to be validly tagged - big deal. At least with the 'uncoded' semantic they can use change history for the code table and the record date to derive a short list of what languages "mis" content might be in - a pain, but that's actually more useful that 'some language'.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Monday, June 18, 2007 1:49 PM
To: Peter Constable
Cc: LTRU Working Group; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis"

I really didn't want to start a flame about this; I'm sorry if what I said was be considered incendiary.

This whole issue is not really connected with the change from part 2 to part 3, at all. Take your example: it is a problem with your definition of "mis" in BCP 47 whether "brk" were added because of 639-3 OR just because it were added to ISO 639-2! It is an issue whenever new codes could be added that would invalidate previous usage of "mis".

And the sad thing is that this instability in ISO codes is completely avoidable. There is a perfectly good way to have the same functionality *without* being unstable.

 *   Have a code I'll call here "root" (to avoid any misunderstanding about the meaning of "mis".)
 *   Have it be valid to tag any language content with "root".
 *   State that one SHOULD tag as narrowly as possible, thus avoid "root" if there is a more specific language code.
This completely takes the place of the need you see for "mis", *without being unstable*. If I have some Burushaski content, where a code doesn't exist, I tag it with "root". That is valid now, and remains valid forever, even once "brk" is added -- whether "brk" were added because of 639-3 or just because it were added to ISO 639-2.

Mark
On 6/18/07, Peter Constable <[email-masked]<mailto:[email-masked]>> wrote:

Peter

From: [email-masked]<mailto:[email-masked]> [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Mark Davis
Sent: Monday, June 18, 2007 9:23 AM
To: Peter Constable
Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; LTRU Working Group
Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"

Mark

Peter

--
Mark

_______________________________________________
Ltru mailing list
[email-masked]<mailto:[email-masked]>
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Mon, 18 Jun 2007 21:58:48 -0700

From: Peter Constable [mailto:[email-masked]]
Sent: Monday, June 18, 2007 10:17 AM

> And note that this issue exists whether one considers
> "old mis" to have the semantic that Keld is stuck on...

My sincere apologies for having gotten these Swedes mixed up. I should have referred to Kent Karlsson here, not Keld (who, I don't think, is even active here).

Peter

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Jun 2007 14:48:12 +0900

At 13:58 07/06/19, Peter Constable wrote:
>My sincere apologies for having gotten these Swedes mixed up. I should have 
>referred to Kent Karlsson here, not Keld (who, I don't think, is even 
>active here).

And who isn't Swedish, but Danish, as far as I know.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 19 Jun 2007 10:51:30 +0100

+1

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter Constable
Sent: 18 June 2007 18:17
To: LTRU Working Group
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: (iso639.2708) RE: ISO 639-2 decision: "mis"

As far as the JAC is concerned, the intentional semantic of "mis" is what it
has always been. As for the extension, when 639-2 was the only alpha-3 code,
there was only one context to evaluate the extension that would be derived
by that intention; 639-2 did not document the extension, though at least one
application of 639-2 - MARC - did. With the introduction of 639-3 and the
pending introduction of 639-5 as additions to the alpha-3 space, it becomes
clear that the extension must be determined within a context: the cases
where you'd want to use "mis" differ if you're using 639-3 rather than
639-2. But for an application of a given part of 639, the change of
reference name has had no effect on the extension for that context: the
languages encompassed by "mis" in a 639-2 application, for instance, are the
same as they were before.

When it comes to BCP 47, the change of reference name for "mis" is basically
irrelevant because there is a much bigger issue: in RFC4646bis, BCP 47 will
change from being an application of 639-1 and -2 to being an application of
639-1, -2 and -3. That change of context is what creates the issue wrt
interoperability of "mis" in applications of BCP 47: Under RFC 4646,
Burushaski content would be tagged "mis"; under RFC 4646bis, one would
expect new Burushaski content to be tagged "bsk". There's no basis for
matching: that's an interop problem. And note that it has nothing to do with
stability of "mis" supposedly introduced with the name change: with or
without that change, Burushaski content would be tagged differently before
and after. 

And note that this issue exists whether one considers "old mis" to have the
semantic that Keld is stuck on, 'all languages', or the semantic that the
JAC has always intended: either way, it is the addition of 639-3 to BCP 47
that creates an issue for uses of "mis" under BCP 47, not the name change. 

context of 639-2 could narrow - inherently by the nature of the semantic -

Therefore, I suggest that beating up ISO as not being in tune with the needs
of the IT community is both fruitless and baseless, and is ignoring the fact
that IETF has problems all of its own making. If IETF really wanted to avoid
any stability or interop problems related to "mis", it should never have
permitted its use in language tags, starting back in RFC 1766, because "mis"
has always had stability / interop issues. But that horse is long out of the
barn: "mis" *can* be used in language tags under RFCs from 1766 to 4646. The
LTRU WG within IETF needs to decide what to do about that in RFC 4646bis.
That's a job for IETF; we don't need to continue bothering JAC members with
IETF issues.

Peter

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Davis
Sent: Monday, June 18, 2007 9:23 AM
To: Peter Constable
Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
LTRU Working Group
Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"

Mark

On 6/16/07, Peter Constable <[email-masked]
<mailto:[email-masked]> > wrote:

From: Kent Karlsson [mailto:  <mailto:[email-masked]>
[email-masked]]

Peter

-- 
Mark

---

From: Keld Jørn Simonsen <[email-masked]>
Date: Tue, 19 Jun 2007 18:21:57 +0200

> And who isn't Swedish, but Danish, as far as I know.

I can comfirm that I am Danish, and that I listen in on this.
Bu, indeed, my activity is low here.

best regards
Keld

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 19 Jun 2007 12:16:25 -0700

"root" would be just as useful as "mis", if you stipulation that people
should tag with as much information as they have. The practical effect would
be little different except that "root" would remain valid.

But the fundamental problem with "mis" is that it is unstable, and
ill-defined. If I get "mis" in a year from now I have no idea whether the
original item was tagged when "mis" first came out (1998?), or in 4646, or
in 4646bis; I just don't know and can't know. If you had defined "mis" to be
"whatever didn't have a code in 1998", that would at least be stable, and
allow valid tags to remain valid.

And frankly, if you are going to the trouble to tag content that you're
going to later revisit, you'd be far better off to use a unique private use
code for each missing item. That way you don't have to re-analyse each piece
of content having "mis" on it.

Anyway, it sounds like the last language proposed for "mis" is ok with
everyone, so this discussion is really moot. Sorry to have raised your
hackles with my original message.

Mark

On 6/18/07, Peter Constable <[email-masked]> wrote:
>
>  Suggesting that 'root' avoids problems is, IMO, rather a bit of false
> economy. Sure, if a tag means 'some language', then content so tagged never
> becomes **incorrectly** tagged when an ID for the given language is added.
> But let's consider whether it is **usefully** tagged: changing things so
> that it could continue to be **correctly** tagged wouldn't make it more **
> usefully** tagged, and arguably makes it less so.
>
>
>
> To suggest that users needn't worry about their content tagged 'root'
> after a new language is coded is IMO bad advice. They certainly **should**
> worry if they want their data to be useful: they'll want to re-tag the
> relevant content with the newly-coded ID, else they end up with data that
> won't compare. At least if they know that the addition will narrow the
> extension and potentially invalidate tagging on some of their content,
> they're more likely to pay attention; what you suggest can give the
> impression that they don't have any particular worry, which is not the case.
>
>
>
>
> A tag with the 'root' semantic can always mean anything – which means it's
> nearly void of meaning and is about as useful as not having tagged it at all
> in the first place. (The 'root' semantic would be equivalent to 'not zxx'.)
> That's not **usefully** tagged, but it's vacuously always going to be
> validly tagged – big deal. At least with the 'uncoded' semantic they can use
> change history for the code table and the record date to derive a short list
> of what languages "mis" content might be in – a pain, but that's actually
> more useful that 'some language'.
>
>
>
>
>
> Peter
>
>
>
> *Sent:* Monday, June 18, 2007 1:49 PM
> *To:* Peter Constable
> *Cc:* LTRU Working Group; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis"
>
>
>
> This whole issue is not really connected with the change from part 2 to
> part 3, at all. Take your example: it is a problem with your definition of
> "mis" in BCP 47 whether "brk" were added because of 639-3 OR just because it
> were added to ISO 639-2! It is an issue whenever new codes could be added
> that would invalidate previous usage of "mis".
>
>    - State that one SHOULD tag as narrowly as possible, thus avoid
>    "root" if there is a more specific language code.
>
> On 6/18/07, *Peter Constable* <[email-masked]> wrote:
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 19 Jun 2007 12:25:07 -0700

Hi -

> From: "Mark Davis" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, June 18, 2007 3:02 PM
> Subject: Fwd: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis"
>

...

As cranky list admin and co-chair -

With no comment on this specific message, I would ask that all
posters to this list carefully consider:
   (1) does my post help advance the completion of the ltru WG's work?
       (e.g., address a specific problem by proposing specific text
       for the documents we are working on)
   (2) if cross-posting, does the message also advance the progress
       of the other mailing lists' work?
   (3) if you still think you need to cross-post, consider whether the
       issue might need to be split up into distinct questions to be
       addressed on the appropriate list.

I'm actually starting to suspect the recipient threshold isn't low enough;
the overwhelming majority of the ltru/ietf-languages crossposts have been,
in my opinion, questionable if not simply inappropriate.

Randy

---

From: Martin Duerst <[email-masked]>
Date: Wed, 20 Jun 2007 14:17:02 +0900

At 04:16 07/06/20, Mark Davis wrote:
>And frankly, if you are going to the trouble to tag content that you're going to later revisit, you'd be far better off to use a unique private use code for each missing item. That way you don't have to re-analyse each piece of content having "mis" on it. 

It may be possible that such a thing is used interally, but not
sent out over the Internet, i.e. that "mis" is used on the Internet.

Regards,    Martin.