> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

> 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...

I have feet in both the "implementors" and "linguistic purists" camps,
and so think I understand both. But there are many points on which I
don't agree with your assessment.


> From [the implementors'] 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.

I would say as an implementor that it's important to find appropriate
ways to match tags that meet legitimate needs in realistic scenarios in
the best way we can, and to be aware of behaviour that will be
experienced when using existing implementations, making sure that any
degredation of behaviour is known and accepted to be offset by benefits,
and that there are no really bad behaviours that may result. I would
consider exact linguistic purity secondary since this system is not
intended to document linguistic realities but to provide useful
behaviours related to differences in language usage in information
systems.



> From [the implementors'] 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.

Here, I disagree, unless this statement is to be understood in a
hypothetical way -- a priori, it would be possible to make changes that
are harmful, but I do not assume that addition of new tags is
necessarily harmful.


> 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 no new forms of tags proposed! 

The draft would impose *restraints* on the forms that tags can take, and
define precisely what forms tags could take. 

This is a point where there may be some "talking past each other". Some
people are speaking from a position in which it is assumed that the part
of a tag that refers to country can be predicted to be in the
second-subtag position. Those supporting the draft are responding that
RFC 3066 does not assume this; it only implies that the only case in
which a country code can be reliably recognized as such is when it is
the second subtag. The former assume that we should continue to keep
country codes in second position because that's the place we've been
able up to now to recognize it. The latter respond that 

- existing implementations will still be able to recognize it when its
in that place

- RFC 3066 permits it to come in other places, but existing
implementations will never be able to recognize it more than
heuristically

- that the new draft would allow new implementations to *always*
recognize it in any tag, and

- *as implementors* it is thought that requiring that country codes only
ever come in that place is *not* what will provide the best behaviours
for users (specifically in cases where script and country subtags are
both used).



> For [linguistic purists], 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.

For the linguist, what matters is the functional behaviour of the
system, including matching, but not the implementation. The linguist,
per se, has no opinion on what the internal structure of tags should
look like; they only specify what the functional requirements of the
overall system should be, and which tradeoffs in functionality are
better or worse.

But maybe I haven't got the same picture of the distinction between the
"implementor" and the "linguistic purist" that you intend. 


 
> A second type of argument... 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,

The question of what the relationship between the naming scheme an
ontologies is important inasmuch as knowing the ontology informs us of
what kinds of distinctions need to be made and kinds of relationships
may exist between those kinds of distinctions, and that guides us in
determining functional requirements, which should be the basis of
implementations. (Once again, a pointer to a white paper on these issues
from a few years ago:
http://www.sil.org/silewp/abstract.asp?ref=2002-003.) 


> 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),

Insofar as tags are structures as linearly-sequenced elements and that
there are matching algorithms in use that are based on
left-prefix-trunctation, there is no debate over *wanting* a
hierarchical structure: it's a reality we must live with.


> or indeed [wants to] 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").

This seems to assume that those promoting an ordering of script and
country subtags as found in the draft are supporting that order for
reasons of linguistic purity and have no interest in discussion of
algorithmic matching, which is completely wrong: the reason for
supporting that order of subtags has everything to do with matching
behaviour in certain widely-deployed algorithms.



Peter Constable

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Reply via email to