Subject: [Ltru] Confirmation question about registry fields

From: Felix Sasaki <[email-masked]>
Date: Thu, 16 Oct 2008 15:29:59 +0900

Hi all,

I am working on an XML version of the registry
http://www.w3.org/2008/05/lta/02/lsr.xml
with the purpose of making it maller in terms of file size. See the XML
Schema at
http://www.w3.org/2008/05/lta/02/lsr.xsd
for the structure description. One part of this approach is to represent
as many fields as possible as attribute values. My question is whether
the only fields which may appear more than once (and hence must be
represented as elements) are "description" and "prefix".

Thank you,

Felix

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 16 Oct 2008 08:40:58 +0200

On Thu, Oct 16, 2008 at 03:29:59PM +0900,
 Felix Sasaki <[email-masked]> wrote 

> I am working on an XML version of the registry

That will be the third one <http://www.langtag.net/registries.html> 
and still no YAML or JSON version :-)

> with the purpose of making it maller in terms of file size.

I would prefer gzip (or a different and more compact format, like the
two mentioned above).

> My question is whether the only fields which may appear more than
> once (and hence must be represented as elements) are "description"
> and "prefix".

No, there is Comments, too. 3.1.2:

>   Field-names MUST occur no more than once per record, with the
>   exception of the 'Description', 'Comments', and sometimes the
>   'Prefix' field.

Also, it seems to contradict the spirit of 3.1.2:

>   Future versions of this document might add additional fields to
>   the registry; implementations SHOULD ignore fields found in the
>   registry that are not defined in this document.

While it is not explicit, it may indicate that a "once only" field
could become a "several occurrences" field later.

field MUST appear only once.
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Felix Sasaki <[email-masked]>
Date: Thu, 16 Oct 2008 22:17:49 +0900

> and still no YAML or JSON version :-)

Yes, I know. So I won't even try to advertise this new version :)

>>   exception of the 'Description', 'Comments', and sometimes the

thanks for the pointer. /me looking at the registry did not find an 
example of an entry with several comments, though.

> could become a "several occurrences" field later.

I had first a version of this XML registry with all fields as elements. 
The version I have now with most of the fields is 1/2 size - around 7K 
for the registry update. So using (of course non-repeatable) attributes 
has a significant benefit.

Felix

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 16 Oct 2008 07:36:24 -0700

> could become a "several occurrences" field later.

I disagree. I think that the fields which are currently "once only" cannot logically change later, with one possible exception, and that such a change is not implied by the quoted text in 3.1.2. That text deals with (for example) the case we have transitioning from 4646 to this document, with the addition of Scope and Macrolanguage to the registry. We might add more key values in the future, but I would be rather surprised to see changes to the existing keys and their definitions. In particular, 3.1.2 is a kind of promise to implementations that, while additional "gunk" might be *added* in the future, breaking changes will be contemplated with utmost caution. 

- Type

By definition, a subtag can only have one type.

- Subtag, Tag

By definition, a record can only have one tag or subtag in it.

- Scope

By definition, this is an enumerated, mutually-exclusive set.

- Macrolanguage

By definition, a language cannot be encompassed by more than one language in ISO 639-3.

- Deprecated, Added

A subtag can only be added or deprecated once.

- Suppress-Script

By definition, there can be only one script that a language is written in "predominantly".

- Preferred-Value

This one is troublesome. There are some values that might be deprecated in favor of more than one item (notably countries splitting into multiple countries, with no country maintaining the original identity---think YU or SU).

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

---

From: John Cowan <[email-masked]>
Date: Thu, 16 Oct 2008 15:28:13 -0400

> By definition, a language cannot be encompassed by more than one

Is that really 100% clear from the text of 693-3?

-- 
                Si hoc legere scis, nimium eruditionis habes.
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Thu, 16 Oct 2008 14:32:31 -0700

Interesting point. The standard, indeed, doesn't impose any such restriction.

There are a couple of theoretical possibilities here:

1) C is macrolanguage-encompassed by B, C is macrolanguage-encompassed by A, and B is macrolanguage-encompassed by A

2) C is macrolanguage-encompassed by B, C is macrolanguage-encompassed by A, but B is not macrolanguage-encompassed by A and A is not macrolanguage-encompassed by B

It seems that in case 1, it shouldn't be necessary to declare 'A is macrolanguage of' as a property of C as long as the other two are declared: the encompassment is necessarily transitive (A must encompass C) -- even though that transitivity isn't explicitly stated, I don't see any other reasonable interpretation.

As for 2, I'd hope the JAC would never create such a situation in the data.

Peter

---

From: John Cowan <[email-masked]>
Date: Thu, 16 Oct 2008 17:38:36 -0400

Peter Constable scripsit:

> 1) C is macrolanguage-encompassed by B, C is macrolanguage-encompassed
> by A, and B is macrolanguage-encompassed by A

A and B are nested macrolanguages here.  I agree that this isn't special:
Chinese is a macrolanguage, and Min Chinese might be a nested
macrolanguage covering the four individual languages of Northern,
Southern, Eastern, and Western Min.

> 2) C is macrolanguage-encompassed by B, C is macrolanguage-encompassed
> by A, but B is not macrolanguage-encompassed by A and A is not
> macrolanguage-encompassed by B

A and B are overlapping macrolanguages here.  This doesn't seem too
preposterous to me; for example, A might encompass English-based creoles,
whereas B might encompass Atlantic creoles.

So I think we ought to allow for the possibility of more than one "Macrolanguage"
header.

Things get really evil with:

3) C is encompassed by B, B is encompassed by A, and A is encompassed by C.

We really, really don't want to go there.

-- 
John Cowan  http://ccil.org/~cowan  [email-masked]
All "isms" should be "wasms".   --Abbie
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Felix Sasaki <[email-masked]>
Date: Fri, 17 Oct 2008 09:16:48 +0900

> So I think we ought to allow for the possibility of more than one "Macrolanguage"

I changed that in my registry version, e.g. from
<lta:ext ty="extlang" su="yue" ad="2029-09-09" pr="yue" 
*ma="zh"*><lta:ds>Yue Chinese
</lta:ds><lta:pref>zh</lta:pref></lta:ext>
to
<lta:ext ty="extlang" su="yue" ad="2029-09-09" 
pr="yue">*<lta:ma>zh</lta:ma>*<lta:ds>Yue Chinese
</lta:ds><lta:pref>zh</lta:pref></lta:ext>
The file gets 8KB larger.

Felix