Subject: [Ltru] More on combination type/scope field

From: "Doug Ewell" <[email-masked]>
Date: Mon, 2 Jun 2008 00:27:28 -0600

Here are some statistics, taken from the current ISO 639-3 data, which 
may be relevant to my suggestion to create an informative field in the 
Registry that combines the "scope of denotation" and "type of language" 
fields from 639-3.

The "scope of denotation" field includes the following values:

- Collective
- Individual
- Local
- Macrolanguage
- Special

The "type of language" field includes the following values:

- Ancient
- Constructed
- Extinct
- Historic
- Living
- Special

Although these are somewhat disjoint data sets, the data contained 
within the two is currently constrained in such as way that it can be 
combined into one field, as seen below:

1. All codes of type "Ancient," "Constructed," "Extinct," and "Historic" 
are of scope "Individual."

2. All codes of scope "Macrolanguage" are of type "Living."  (In fact, 
it seems unlikely that a non-living language would be designated a 
macrolanguage in the future.)

3. All codes of scope "Special" are also of type "Special," and vice 
versa.  These are 'mis', 'mul', 'und', and 'zxx'.

4. Codes of scope "Collective" do not have a designated type.  These are 
the collection codes traditionally associated with 639-2, and now 
unambiguously associated with 639-5.  There are 113 of these.

5. Codes of scope "Local" do not have a designated type.  These are the 
520 private-use codes 'qaa' through 'qtz', which occupy just one listing 
in the LSR.

Given this, we could add an optional "Scope" field (or pick a better 
name) to language and extlang records in the LSR with exactly one of the 
following values, with no ambiguity:

- ancient
- collective (or "collection")
- constructed
- extinct
- historic
- local
- macrolanguage
- special

and omit this field for the language subtags that are "individual" and 
"living," which are 89.8% of the total (7019 out of 7816) and thus can 
be treated as the default.

Alternatively, if combining the fields is too distasteful for some, we 
could add separate "Language-Type" and "Scope" fields corresponding to 
the two ISO 639-3 designations.  In that case, I suggest omitting the 
"Language-Type" field when the value is "living," and omitting the 
"Scope" field when the value is "individual," since these are the 
overwhelming majority and can be treated as defaults.

--
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: Mon, 02 Jun 2008 10:19:25 +0200

Doug Ewell 2008-06-02 08.27:

> [...] Given this, we could add an optional "Scope" field (or 
> pick a better name) to language and extlang records in the LSR
> with exactly one of the following values, with no ambiguity:
> 

> could add separate "Language-Type" and "Scope" [...]

With a clear name, one field can be better than two.

As for the name, "which/what scope" is not the first question I 
would ask first in order to learn which of those values that fits.

Whereas "what kind (of language)" seems natural. Hence Kent's 
mention of "kind" has my support.

Another, clear name is "Kind-of-language", unless a 3-word-name is 
out of scope.

(If feel that "type" goes more on the linguistic features of the 
language -- if anyone wonders how I compare "language-type" and 
"kind-of-language".)
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Mon, 02 Jun 2008 16:48:42 +0900

Okay, here is Doug's proposal the way I understand it, in table form
(please use non-proportional font to view it):
[by the way, I like Addison's proposal, too]

(Language-)Type  Scope          Number   Examples         Proposal Doug

Ancient          Individual                               Ancient
Constructed      Individual                               Constructed
Extinct          Individual                               Extinct
Historic         Individual                               Historic
Living           Individual                               -
Living           Macrolanguage                            Macrolanguage
Special          Special        4        mis/mul/und/zxx  Special
-                Collective     113                       Collecti(ve|on)
-                Local          520                       Local

I think this goes into the right direction. I'm not sure I understand
the distinction between Ancient, Extincts, and Historic, but I don't
bother. I'm marginally affraid that we will have to reopen the WG
if in the future, there is a case where the above scheme fails.
Therefore, I suggest to clarify by saying (very roughly) "the *Foo*
field contains the information in the Type and Scope fields of ISO 639-3.
Values of 'Living' for 'Type' and 'Individual' for Scope are default
and therefore omitted. If both values are the same, only one word is
used. The order of the values is undefined. If the field is empty,
it is not used."

This would give us the freedom to have
   Language-Type: Ancient Macrolanguage
or
   Language-Type: Macrolanguage Ancient
if something like that ever becomes necessary in the future.

Also, I don't care about Collective vs. Collection (I think we
therefore best leave it as is), but I think changing "Local"
to "Private" would help the readers of the registry, because
that's the general IETF terminology.

Regards,    Martin.

At 15:27 08/06/02, Doug Ewell wrote:
>Here are some statistics, taken from the current ISO 639-3 data, which >may 
>be relevant to my suggestion to create an informative field in the 
> >fields from 639-3. > >The "scope of denotation" field includes the following 
>values: > >- Collective >- Individual >- Local >- Macrolanguage >- Special > >The 
>"type of language" field includes the following values: > >- Ancient >- 
>Constructed >- Extinct >- Historic >- Living >- Special > >Although these are 
>somewhat disjoint data sets, the data contained >within the two is 
>currently constrained in such as way that it can be >combined into one 
>field, as seen below: > >1. All codes of type "Ancient," "Constructed," 
>"Extinct," and "Historic" >are of scope "Individual." > >2. All codes of 
>scope "Macrolanguage" are of type "Living."  (In fact, >it seems unlikely 
>that a non-living language would be designated a >macrolanguage in the 
>future.) > >3. All codes of scope "Special" are also of type "Special," and 
>vice >versa.  These are 'mis', 'mul', 'und', and 'zxx'. > >4. Codes of scope 
>"Collective" do not have a designated type.  These are >the collection 
>codes traditionally associated with 639-2, and now >unambiguously 
>associated with 639-5.  There are 113 of these. > >5. Codes of scope "Local" 
>do not have a designated type.  These are the >520 private-use codes 'qaa' 
>through 'qtz', which occupy just one listing >in the LSR. > >Given this, we 
>could add an optional "Scope" field (or pick a better >name) to language 
>and extlang records in the LSR with exactly one of the >following values, 
>with no ambiguity: > >- ancient >- collective (or "collection") >- 
>constructed >- extinct >- historic >- local >- macrolanguage >- special > >and 
>omit this field for the language subtags that are "individual" and 
> >"living," which are 89.8% of the total (7019 out of 7816) and thus can >be 
>treated as the default. > >Alternatively, if combining the fields is too 
>distasteful for some, we >could add separate "Language-Type" and "Scope" 
>fields corresponding to >the two ISO 639-3 designations.  In that case, I 
>suggest omitting the >"Language-Type" field when the value is "living," and 
>omitting the >"Scope" field when the value is "individual," since these are 
>the >overwhelming majority and can be treated as defaults. > >-- >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 
> $B%R+(B>_______________________________________________ >Ltru mailing 
>list >[email-masked] >https://www.ietf.org/mailman/listinfo/ltr

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

---

From: "Kent Karlsson" <[email-masked]>
Date: Mon, 2 Jun 2008 10:52:16 +0200

Doug Ewell wrote:
> 520 private-use codes 'qaa' through 'qtz', which occupy just 
> one listing in the LSR.

Isn't "local" just another word for "private-use"?

Otherwise Doug's proposal is fine by me.

	/kent k

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 2 Jun 2008 07:16:50 -0600

> With a clear name, one field can be better than two.

Noted.

> As for the name, "which/what scope" is not the first question I would 
> ask first in order to learn which of those values that fits.
>
> Whereas "what kind (of language)" seems natural. Hence Kent's mention 
> of "kind" has my support.

I worry about non-native English speakers, or even native English 
speakers, drawing a clear distinction between the words "type" and 
"kind."  To me they are perhaps too similar.

> Another, clear name is "Kind-of-language", unless a 3-word-name is out 
> of scope.

Since we already have "Preferred-Value" and "Suppress-Script," this 
would not be a limitation.

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 2 Jun 2008 07:36:38 -0700

I think this is a Bad Idea: it puts us into the business of collecting/determining all manner of information about language codes. The collection and macrolanguage codes we know because one of the ISO 639 parts tells us. I suppose the 'special' codes we know because we list them. We don't need to become a competitor to or mirror of Ethnologue, Linguist List or Wikipedia.

What we call the field is of less import to me. If we're going to "kind of language", then perhaps the field could be calls "Classification". And the values could be from ISO 639-3/-5:

 collection
 macrolanguage
 individual  (as in Ethnologue's "individual language")

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leif Halvard Silli
> Sent: Monday, June 02, 2008 1:19 AM
> To: Doug Ewell
> Cc: LTRU Working Group
> Subject: Re: [Ltru] More on combination type/scope field
>

---

From: John Cowan <[email-masked]>
Date: Mon, 2 Jun 2008 11:35:51 -0400

I've just added some counts, to give people an idea:

> - ancient [113 entries in 639-3]
> - collective (or "collection") [113 entries in 639-5]
> - constructed [20 entries in 639-3]
> - extinct [426 entries in 639-3]
> - historic [63 entries in 639-3]
> - local [520 entries in 639-2]
> - macrolanguage [57 entries in 639-3]
> - special [4 entries in 639-3]
> 

In response to Martin's non-question:  Ancient languages have been extinct
for 50 years or more; extinct languages for a lesser period; historic
languages are earlier stages of living languages, like Old English.
The effective difference between ancient languages and extinct ones is
that Language List does change control for ancient, constructed, and
historic languages, whereas Ethnologue does it for living and extinct
languages.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts....  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Mon, 2 Jun 2008 11:36:49 -0400

Phillips, Addison scripsit:

> I think this is a Bad Idea: it puts us into the business of
> collecting/determining all manner of information about language
> codes. The collection and macrolanguage codes we know because one
> of the ISO 639 parts tells us. I suppose the 'special' codes we know
> because we list them. We don't need to become a competitor to or mirror
> of Ethnologue, Linguist List or Wikipedia.

This is all information direct from 639-3, so it's in our remit.

-- 
As we all know, civil libertarians are not      John Cowan
the friskiest group around --comes from        [email-masked]
forever being on the qui vive for the sound     http://www.ccil.org/~cowan
of jack-booted fascism coming down the pike.           --Molly Ivins
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Mon, 2 Jun 2008 11:44:13 -0400

> This is all information direct from 639-3, so it's in our remit.

Specifically columns 5-6 of
http://www.sil.org/iso639-3/iso-639-3_20080529.tab .

-- 
Long-short-short, long-short-short / Dactyls in dimeter,     John Cowan
Verse form with choriambs / (Masculine rhyme):           [email-masked]
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time.     --robison who's at texas dot net
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Mon, 2 Jun 2008 08:50:43 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Cowan

> historic languages, whereas Ethnologue does it for living and extinct

The more significant distinction is that ancient languages have a body of literature -- which is why we know about them, whereas extinct language likely do not have a body of literature -- we know about them because they died out recently enough for someone to document their existence, but because not enough literature (if any) had developed to sustain vitality the language died as younger generations moved to more developed languages.

Peter

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 2 Jun 2008 10:22:30 -0700

> This is all information direct from 639-3, so it's in our remit.

Yes, but I still don't think we should mirror it. We would have to mirror the explanations for the values in the RFC, track changes to the values, and otherwise encumber ourselves with various maintenance and explanatory details. The less we do in the registry by fiat, the more flexible we will be.

I have to admit to being at least a little leery of the (necessary and unavoidable) fluctuations that will come from any embrace of "splitter" (vs. "lumper") linguistic categorization schemes. There is no end to the ways that one can split up and categorize language. The less of the non-normative information we mirror, the easier the maintenance work and the less likely we will find ourselves embroiled in long-winded and painful (yet ultimately meaningless) discussions on ietf-languages.

Addison

Addison Phillips

---

From: John Cowan <[email-masked]>
Date: Mon, 2 Jun 2008 13:31:10 -0400

Phillips, Addison scripsit:

> Yes, but I still don't think we should mirror it. We would have to
> mirror the explanations for the values in the RFC, track changes to the
> values, and otherwise encumber ourselves with various maintenance and
> explanatory details. The less we do in the registry by fiat, the more
> flexible we will be.

Fair enough.  Well, we do talk about language collections in the draft,
and the private use codes are currently marked with a "Description:"
field only (plus having special magic syntax), so how about abandoning
ISO 639 type and having a minimalistic Scope field with "Collection"
and "Private use" field values?

-- 
Newbies always ask:                             John Cowan
  "Elements or attributes?                      http://www.ccil.org/~cowan
Which will serve me best?"                      [email-masked]
  Those who know roar like lions;
  Wise hackers smile like tigers.                   --a tanka, or extended haiku
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 2 Jun 2008 23:11:59 -0600

I'm going to try to format this manually into 72 columns, which won't be
pretty or fun.

Martin Duerst wrote:

> ...

(John Cowan filled in the remaining counts; not surprisingly, they
matched mine perfectly.)

Martin continued:

> bother.

The important difference for our purposes is that ISO 639-3 defines
these languages as Ancient, those as Extinct, and those over there as
Historic. It's their mapping.

> I'm marginally affraid that we will have to reopen the WG if in the
> future, there is a case where the above scheme fails. Therefore, I
> suggest to clarify by saying (very roughly) "the *Foo* field contains
> the information in the Type and Scope fields of ISO 639-3. Values of
> 'Living' for 'Type' and 'Individual' for Scope are default and
> therefore omitted. If both values are the same, only one word is used.
> The order of the values is undefined. If the field is empty, it is not
> used."
>

I would be fine with this.

> therefore best leave it as is), but I think changing "Local" to
> "Private" would help the readers of the registry, because that's the
> general IETF terminology.

> Isn't "local" just another word for "private-use"?

I was trying to keep ISO's terminology intact.  If we want to map them
to other words, that's OK (I prefer "Private" too), as long as this
doesn't open the door to redrawing the boundaries.

Addison countered:

> collecting/determining all manner of information about language codes.
> The collection and macrolanguage codes we know because one of the ISO
> 639 parts tells us. I suppose the 'special' codes we know because we
> list them. We don't need to become a competitor to or mirror of
> Ethnologue, Linguist List or Wikipedia.

I would never have suggested this if the information weren't handed to
us on a silver platter by ISO 639-3.  Everyone knows how critical I am
of efforts to supersede or second-guess the RAs responsible for the
core standards.

> What we call the field is of less import to me. If we're going to
> "kind of language", then perhaps the field could be calls
> "Classification". And the values could be from ISO 639-3/-5:
>
>  collection
>  macrolanguage

This is the "lite" version of my proposal, scaled down to cover two of
the five "Scope" values in 639-3 and to ignore the Language-Type field.
We could do that -- it would answer the most common questions about
collections vs. macrolanguages -- but I thought we might take the
opportunity to answer, in one word, the somewhat less common living/
ancient/constructed question as well.  Certainly I would never suggest
expanding this to the full Ethnologue or Linguist List description, or
embarking on our own research.  God, no.  We can't even agree on that
for Suppress-Script.

> mirror the explanations for the values in the RFC,

No, we wouldn't.  We would have to say that they follow [ISO 639-3].

> track changes to the values,

Which will be a lot less work for the Designated Registry Clerk than
trying to figure out which changes represent "narrowing," and inserting
mandatory Comments fields in the LSR when they do, a suggestion which
garnered some WG support.

> and otherwise encumber ourselves with various maintenance and
> explanatory details.

It's in the very same ISO 639-3 file I'll be using to track their dozens
of updates anyway.

> The less we do in the registry by fiat, the more flexible we will be.

"Flexible" in what sense?  After all this discussion of picking and
choosing the features of ISO 639 and 3166 we like and discarding the
ones we don't, I think 4646bis could use a bit more rigidity.

> I have to admit to being at least a little leery of the (necessary and
> unavoidable) fluctuations that will come from any embrace of
> "splitter" (vs. "lumper") linguistic categorization schemes. There is
> no end to the ways that one can split up and categorize language.

We claim in our documents to follow ISO 639-*, for some value of
"follow."  It's their model; they get to take responsibility and praise
and criticism for it.  We only get into quicksand to the extent we
choose to adapt and redefine their model.

> The less of the non-normative information we mirror, the easier the
> maintenance work and the less likely we will find ourselves embroiled
> in long-winded and painful (yet ultimately meaningless) discussions on
> ietf-languages.

If we include this information in the LSR, and someone asks ietf-
languages what it is or why things are defined that way or couldn't we
change this or that, the reply would be simple and straightforward --
it's a distillation of what ISO says, and no, we won't override them --
unless of course ietf-languages chooses to join in the second-guessing
game.  If we don't include it, the type of questions that ietf-languages
will likely be very open-ended.

John replied:

> Fair enough.  Well, we do talk about language collections in the
> draft, and the private use codes are currently marked with a
> "Description:" field only (plus having special magic syntax), so how
> about abandoning ISO 639 type and having a minimalistic Scope field
> with "Collection" and "Private use" field values?

I think "Private" already speaks for itself, with that big ALL-CAPITALS
description.  I'd actually prefer "Collection" and "Macrolanguage," so
people could see that they aren't the same, or interchangeable.  But
this is at least moving toward some level of agreement.

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 3 Jun 2008 00:18:51 -0700

I agree in general with Addison, about not loading down the repository with
information that can be found elsewhere (especially where that information
may change over time).
However, I agree with John that PrivateUse codes are special in terms of
architecture of LTRU, are called out in the spec, and should be
distinguished by more than just a Description. I'm not sure about whether
the Collections should qualify, since I don't think we don't have any part
of LTRU, either the spec or usage, that depends on whether a code is a
Collection or not.
Mark

-- 
Mark

---

From: John Cowan <[email-masked]>
Date: Tue, 3 Jun 2008 09:36:12 -0400

> of LTRU, either the spec or usage, that depends on whether a code is a

See section 4.1, bullet point 4.1, in draft 14.

-- 
John Cowan       http://www.ccil.org/~cowan        <[email-masked]>
        You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
        You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
                Clear all so!  `Tis a Jute.... (Finnegans Wake 16.5)
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Tue, 3 Jun 2008 06:56:12 -0700

I think private use and collection IDs are worth identifying as such. I agree that we don’t need to include categories such as historic, etc.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Tuesday, June 03, 2008 12:19 AM
To: John Cowan
Cc: LTRU Working Group
Subject: Re: [Ltru] More on combination type/scope field

I agree in general with Addison, about not loading down the repository with information that can be found elsewhere (especially where that information may change over time).

However, I agree with John that PrivateUse codes are special in terms of architecture of LTRU, are called out in the spec, and should be distinguished by more than just a Description. I'm not sure about whether the Collections should qualify, since I don't think we don't have any part of LTRU, either the spec or usage, that depends on whether a code is a Collection or not.

Mark
On Mon, Jun 2, 2008 at 10:31 AM, John Cowan <[email-masked]<mailto:[email-masked]>> wrote:

--
Newbies always ask:                             John Cowan
 "Elements or attributes?                      http://www.ccil.org/~cowan
Which will serve me best?"                      [email-masked]<mailto:[email-masked]>
 Those who know roar like lions;
 Wise hackers smile like tigers.                   --a tanka, or extended haiku
_______________________________________________
Ltru mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 3 Jun 2008 09:46:56 -0700

Good point; I hadn't been looking at the latest draft.

---

From: "Kent Karlsson" <[email-masked]>
Date: Tue, 3 Jun 2008 19:11:32 +0200

Mark Davis  wrote: 

See the quoted text below that calls for special caution for using "Collection" codes, and continues with cautioning against special codes. I don't like relying on a particular word being present in the English description field, but rather have that in a separate field for the purpose. I'd be happy limiting this to just the values <individual (default, not given explicitly in LSR), macrolanguage, collection, special, private use (call it "local" if you like)>. And then to have the following text refer to "individual language codes/subtags" rather than "specific language subtags". "Specific" does not mean quite the same as "individual", though here they apparently mean the same. This would leave out info on <living, constructed, historic, ancient, ...> in the LSR, and that is ok I think, if there are too many objections.
 
B.t.w., I think the first reference should be to -3 and -5, not (just) -2.
 
        /kent k
 
=========================================
 <http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-15.html#ISO639-2> [ISO639‑2] (International Organization for Standardization, “ISO 639-2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition,” 1998.) has defined several codes included in the subtag registry that require additional care when choosing language tags. In most of these cases, where omitting the language tag is permitted, such omission is preferable to using these codes. Language tags SHOULD NOT incorporate these subtags as a prefix, unless the additional information conveys some value to the application. 

1.	Use specific language subtags or subtag sequences in preference to subtags for language collections. A "language collection" is a subtag derived from one of the  <http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-15.html#ISO639-5> [ISO639‑5] (International Organization for Standardization, “ISO 639-5:1998. Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups,” May 2008.) codes that represents multiple related languages. These codes are included as primary language subtags in the registry. For example, the code 'cmc' represents "Chamic languages". The registry contains values for each of the approximately ten individual languages represented by this collective code. Some other examples include the subtags Germanic languages ('gem') or Algonquian languages ('alg'). Since these codes are interpreted inclusively, content tagged with "en" (English), "de" (German), or "gsw" (Swiss German, Alemannic) could also (but SHOULD NOT) be tagged with "gem" (Germanic languages). Subtags derived from collection codes SHOULD NOT be used be used unless more specific language information is not available. Note that matching implementations generally do not understand the relationship between the collection and its encompassed languages, and so users ought not assume a subtag based on a language collection is a useful means for selecting content in its encompassed languages.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Jun 2008 17:24:10 +0200

On Mon, Jun 02, 2008 at 12:27:28AM -0600,
 Doug Ewell <[email-masked]> wrote 
 a message of 17 lines which said:

> Alternatively, if combining the fields is too distasteful for some,
> we could add separate "Language-Type" and "Scope" fields
> corresponding to the two ISO 639-3 designations.  

I prefer this one.The two concepts seem to be on separate axis so
should be represented by different fields.

> In that case, I suggest omitting the "Language-Type" field when the
> value is "living," and omitting the "Scope" field when the value is
> "individual," since these are the overwhelming majority and can be
> treated as defaults.

Why not. But why? For limiting the size of the file? For easier
reading under vi or Notepad?
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru