Subject: [Ltru] draft-06 of matching prototype...

From: "Addison Phillips" <[email-masked]>
Date: Mon, 14 Nov 2005 13:56:48 -0800

Based on Martin's comments from over the weekend, I have produced a heavily reorganized version of draft-matching and uploaded it to my personal website. This copy is intended as a test run to see if it addressed Martin's specific concerns and whether this was really the right approach (does it need doing?)

Basically, what I did was:

1. I separated the definition of Language Ranges from the matching schemes altogether. Both basic and extended language ranges are defined together, then, in a separate section, the "Types of Matching"

2. To make things clearer, I retitled the "matching" matching schemes as "filtering" (so we have "lookup" and "filtering", both of which are matching schemes). I retitled the Distance Metric Scheme as Distance Metric Filtering as well.

3. The text that was in "Choosing a Language Matching Scheme" was incorporated into the introduction to the section on matching schemes.

4. The remaining "junk" (meaning, considerations for private use subtags, and length considerations) were moved into a new, separate section call "Other Considerations". 

5. A rough once-over edit was applied to make the text more-or-less clean.

Martin, et al: is this generally what you have in mind? Is this the right way to proceed? 

HTML: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-06.html
XML: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-06.xml

Best Regards,

Addison

Addison P. Phillips
Globalization Architect, Quest Software
http://www.quest.com

Internationalization is not a feature.
It is an architecture. 

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

---

From: Mark Davis <[email-masked]>
Date: Tue, 15 Nov 2005 09:57:20 -0800

I really like the restructuring. Interesting how much value it is just 
to introduce terminology like 'filtering'; it will make the situation 
much clearer to users.

What I think it also makes clear is that we shouldn't be including 
3.2.2. Extended Range Lookup. A lookup has to give a precise, single 
answer whenever there are a number of possible matches. The formulation 
that the draft gives does not distinguish in priority among matching 
items. If the following are all available, a lookup (as opposed to a 
filter) has to specify which would be the *first choice* when handed 
"*-US":

en-US

es_US

en-Latn-US

en-US-r-extends (extensions are ignored)

nn-US

no-US

en

es

nn

no

I don't know of anyone in practice who implements 3.2.2, so I think this 
should be removed. Some future version of this RFC could be enhanced to 
include something like it, once all the kinks are worked out.

Mark

Addison Phillips wrote:

>------------------------------------------------------------------------
>