Re: [Ltru] Consensus call: extlang

> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of
> Leif Halvard Silli

> If the focus is identification, then the fallback and filtering
> doesn't matter (or must be defined subsequently).

Sorry, but this is not a sensible approach to coding.

By "identification", we're talking about devising a coding scheme that provides code elements used to represent a semantic for the purpose of declaring language identity on information objects, and *also* for use in various kinds of processing on those information objects. If declaring identity was the only purpose, and processing is irrelevant, then all bets are off as to what the best way is to represent identities -- for instance, a URI pointing to some encyclopedic description strikes me as a far better identifier.

Our language tags exist *because* of processing scenarios. Nobody would bother wasting time adding a tag to metadata on information objects if it was just going to _be_, ignored and taking up space.

The coded representation of a semantic category can take any form, and as long as all are equally documented the identificational value of each of those potential forms is exactly equivalent. For instance, "cmn" and "zh-cmn" are exactly equal in terms of identificational value -- meaning "Mandarin". Mark described these as different, but I think the difference he pointed out was one of processing, not one of identity.

If I know the relationship between Mandarin and "Chinese", then I can make exactly the same processing decisions with "cmn" as I can with "zh-cmn". But the two differ wrt what kinds of processing mechanisms are available to me: "cmn" requires that a process have a separate business knowledge relating Mandarin and "Chinese", but "zh-cmn" embeds that knowledge into the tag itself. Since both are the same in terms of their identificational value, the question to be asked is which of these is more useful for processing.

And not just for *this* pair, but for all macrolanguage cases -- unless we're considering using extlang for just certain cases.

> Extlang makes identifying/finding *all* Chinese languages simple,

Note that you have already introduced processing.

> for those that need to do find them all. It would only require
> that you ask for 'zh'. Thus with extlang one could start tagging
> resources spesificly *immediatly*, because it should be highly
> compatible with existing application behaviour.

For applications that use right-truncation matching, but not lookup.

> (Btw, this approach strikes me as higly compatible with another
> popular slogan: Don't break the Web.)

Well, not all servers use right-truncation matching logic, and for those that don't your plan would be breaking the Web. (I'm not saying that the no-extlang path doesn't have some of the same issues; either way, there are things that would need to be done to keep everything working smoothly if we want to transition from a "zh"-only past into a future that includes "cmn"/"yue"/etc.)

Peter
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru