Subject: [Ltru] Re: extlang again

From: "Doug Ewell" <[email-masked]>
Date: Sun, 29 May 2005 18:35:12 -0700

John Cowan <jcowan at reutershealth dot com> wrote:

> Currently you don't have to have access to the registry to do
> matching, only to do validity checking.  I think that's as it should
> be.

Almost true.  You can't match preferred (née canonical) values with
their non-preferred (née alias) equivalents without the registry.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

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

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 31 May 2005 08:05:27 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Frank Ellermann

> Yes, so far it's clear.  What I don't see is a convincing
> reason for multiple levels of redudancy.  From an academical
> POV this is probably fascinating, but is it also important
> in practice ?

> Either they are variants or they are different.  To get this
> right is probably a PITA, but attempts to do both at the same
> time IMHO don't belong in billions of tags in the real world.

We will eventually need to work through all such issues when we are
developing 3066ter. But let me ask: is the immediate issue that you want
to change *("-" extlang) to *n("-" extlang) for some smallish value of
n, such as 5? If so, that would be reasonable to me.

Now, as for the issues you raise, it's reasonably clear that we will not
be facing billions of tags with extlang subtags, let alone multiple
extlang subtags. You can inspect the tables in ISO/DIS 639-3 to find
that there are some 56 macrolanguages (26 of these have alpha-2 IDs)
which together encompass 365 individual languages. (This status of the
code tables is that they are still draft proposals; in particular, the
ISO 639/RA Joint 
Advisory Committee still needs to decide if they want to treat those 56
entries in 639-2 as macrolanguages, as I have proposed.)

Let's imagine that on average each is written with three different
scripts, spoken in five countries, and that five variant subtags are
eventually registered -- an *extreme* unlikelihood; that's around 53000
possible tags involving these extlangs. But again, the assumptions
behind that scenario are very unlikely: there are only a small number of
these that have any likelihood of being written in more than one script;
many are spoken in only one country, and only Arabic and Chinese are
spoken in many countries. I suppose on average there's as much
likelihood of variants being registered for these languages as for any
other. In reality, we're looking at *far* fewer than 53000.

At present, there is no case in the draft code tables for 639-3 of a
macrolanguage that is encompassed by another macrolanguage. So, at
present, there would be no valid 3066ter tag with more than one extlang.
John has described the scenario under which such a thing could arise.
It's something I'd expect would happen rarely. So, the number of tags
you'll ever see multiple extlang subtags, if any, will be very limited.

Now, does it make sense to use extlang subtags? And if the possibility
of multiple extlangs arises would it make to use multiple extlangs? I
think it would, since it provides a workable means for matching where
the request and the items are tagged with different levels of
specificity -- something that *is* likely given that there will be
existing implementations using the more generic value, with the more
specific value becoming possible.

Again, if the immediate issue is to limit the length of possible tags,
let's change the ABNF to allow at most 5 extlangs and move on.

Peter Constable