Re: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I notice two main types of arguments going on in this thread, where it seems to me that there is frustration
and "talking past each other" occurring due to fundamentally different concerns and assumptions between
different constituencies. 

One type of conflict seems to me between what I will term, for convenience (and please, I don't want to get
side-tracked on my choice of terms -- I just want convenient words) "implementors" vs. "linguists".

By "implementors", I mean those whose concern is primarily on how to interpret (act on) received language tags
-- consumers of language tags, where falling back to a "general" or "compatible" match may be desirable when an
exact match is not available.  From their point of view, the most important aspect of language tags is being able to
parse and match them -- exact linguistic purity and accuracy is a secondary issue.  From their point of view, the 
addition of new tags, regardless of whether the new tags improve language tagging "accuracy", may be actively
harmful unless accompanied by improved matching rules.  To the extent that the adding of tags moves beyond
simple registration of new tags, and instead into new forms of tags and new rules for interpreting tags, that is, that
the new tags bring up fundamental matching algorithm questions, that becomes the main concern for this group.

There are what I will refer to as "linguistic purists", whose concern is primarily on having precise, accurate tags
availabel for languages.  (These may be people whose orientation is on generating content, and labelling it 
accurately.)  For this group, the most important aspect of language tags is having them be accurate and precise.
Any matching issue (and in particular issues of trying to fall back to a more "generic" match when an exact match
is not available) are secondary.

The opinion on whether a tag is "useful" then varies: "it's useful if I know how to match it" vs. "it's useful if it's accurate".

An example where the difference in orientation shows up is with the position of script vs. country in tags.  From the
linguistic point of view, there are arguments for having script come first.  But from the implementation point of view,
that is less backwards-compatible with 3066, hence more problematic.

The process question of whether this is appropriately a BCP, or whether it is at least implicitly  bringing up
algorithmic implementation issues and hence instead ought to be perhaps a Proposed Standard or an Experimental 
Standard, also has something to do with this difference in orientation.
 
A second type of argument, (which I should mention I have largely tuned out so this is my superficial and not very
informed take on it), seems to me to be more linguistic/political in nature, which is what is the "correct" (linguistically 
correct? politically correct?) way to name the tags: what sort of naming scheme corresponds to linguistic reality,
or what sort of naming scheme is politically acceptable, and is there a conflict there.  This does get back to the
algorithmic matching issue in a sense though, which is that if one wants some sort of hierarchical structure to
the tags (to allow easier matching), or indeed define any sort of matching rules (as an implementor wants), you're
probably getting right into some political questions about how matching "should work".   So for those who wanted
to stick just to linguistic accuracy and try to avoid political issues, trying to avoid discussion of algorithmic matching
may have seemed appealing (but then provides no help to what I've termed the "implementors").

If we can keep in mind that there are different constituencies interested in language tags, with different main concerns,
then I would hope for less frustration and irritation with others "missing the main point", so that constructive 
discussions can occur, leading to some compromise useful to everyone. 

Regards,

Kristin

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]