Subject: [Ltru] draft-06 comments: choice of range

From: "Addison Phillips" <[email-masked]>
Date: Thu, 17 Nov 2005 12:02:37 -0800

Having had a chance to actually read my handiwork in draft-06, I notice an obvious additional structural change to be made.

Actually, I believe Martin already suggested this.

I notice that the sections on each type of language range now contains a lot of "hand wringing" about what users should choose or not choose. This text is actually applicable to all types of ranges. Thus, it seems to me that a section at the end of Section 2 on "Choice of Language Range" is appropriate.

In my editor's copy of draft-07, I actually performed this change so folks could review it. (I also made some other corrections pointed out off list: these are listed in the changes section)

http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.txt
http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html
http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.xml

Comments?

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: Frank Ellermann <[email-masked]>
Date: Fri, 18 Nov 2005 00:01:55 +0100

Addison Phillips wrote:
 
> In my editor's copy of draft-07

Argh... you're not supposed to change the text before
the previous version is officially announced... ;-)  

Okay, -07 it is, -06 lived on my hard disk for less
than 12 hours.
                     Bye, Frank

---

From: Mark Davis <[email-masked]>
Date: Fri, 18 Nov 2005 10:15:15 -0800

A field not present in the middle of an extended language range MAY be 
treated as if the field contained a "*". For example, the range "en-US" 
MAY be considered to be equivalent to the range "en-*-US". This also 
means that multiple wildcards can be collapsed (so that "en-*-*-US" is 
equivalent to "en-*-US").
=>
A field not present in the middle of an extended language range MAY be 
treated as if the field contained a "*". For example, the range "en-US" 
MAY be considered to be equivalent to the range "en-*-US". When this is 
done, multiple wildcards can be collapsed (so that "en-*-*-US" is 
equivalent to "en-*-US").

[The "this also means" only applies when the implemenation does the MAY.]

----

measurment
[spell-check]

----

[General Observation.

We need to give a mechanism that will always give a precise, determinant 
answer. We then let protocols specify alternatives (if they need to) by 
additional specification. In particular, in each section we have to make 
clear what exactly happens with a language range, and what happens with 
a language priority list.

For filtering, this can be done by moving the discussion of the language 
priority list up into 3.2. ]

3.2.
If the language priority list (see Section 2.1 (Lists of Language 
Ranges) 
<http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html#lists>) 
contains more than one range, the content returned is typically ordered 
in descending level of preference.
=>
If the language priority list (see Section 2.1 (Lists of Language 
Ranges) 
<http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html#lists>) 
contains more than one range, the contents that match that range are 
added to the set of results.

[At the end of the section, after we've introduced the discussion of an 
ordered list and distance metric, add]

When the set of matches is returned, the items are in descending order 
where the weight for each item is the priority in the language priority 
list divided by the distance metric. (If the filtering method does not 
supply a distance metric, then the distance metric is 1.) If the item 
matches multiple ranges, then its weight is the square root of the sum 
of squares of the individual weights for each range. If two items have 
the same weight, then their ordering is based on a case-insensitive 
ordering of the language tags.

A protocol which uses language priority lists MAY specify an alternative 
mechanism for computing the ordering.

----

A protocol which uses language ranges MAY specify additional rules about 
the semantics of "*";
=>
A protocol which uses language ranges MAY specify additional rules about 
the semantics of "*" or other tags;
[no reason to restrict it]

----

Implementations or protocols sometimes might wish to use more 
sophisticated weights that
=>
Implementations or protocols sometimes MAY specify the use of 
alternative weights that

----
[Make subsections in Lookup. First language range lookup, then language 
priority list lookup, then extended language range lookup.]

----
Other examples of lookup might include:
=>
Other examples of lookup include:
[the examples *do* include. no need to be tentative ;-)]
----

If this language range is the only one in the language priority list, it 
matches the default content. If this language range is followed by other 
language ranges, it should be skipped.
[doesn't address  *;*]
=>
All "*" language tags are removed from language priority list. If there 
is nothing left, then it matches the default content.

----

5. (default content or the empty tag)
=>
5. (default)
[explain below what this is. it is also otherwise odd that 1-4 are tags, 
but then this is 'content']

----

When performing lookup using a language priority list, the progressive 
search MUST proceed to consider each language range before finding the 
default content or empty tag. The default content might be content with 
no language tag (or with an empty value, as with xml:lang in the XML 
specification), or it might be a particular language designated for that 
bit of content.

One common way to provide for default content is to allow a specific 
language range to be set as the default for a specific type of request. 
This language range is then treated as if it were appended to the end of 
the language priority list, rather than after each item in the language 
priority list.

=>
[reword for clarity. Funny thing: when I first read 'might be content 
with no language tag' I read it as the verb "be content with", like "be 
happy with". The empty tag is not a valid language tag, so we should say 
"und", then say that a system can use alternatives. Here is the text.]

When performing lookup using a language priority list, the progressive 
search MUST consider each language range before finding the default. The 
default might be specified as "und" (or be indicated with an empty 
value, as with xml:lang in the XML specification, or with "root" as in 
some systems), or it might be specified as a particular language range.  
This language range is thus treated as if it were appended to the end of 
the language priority list, rather than after each item in the language 
priority list.

----

5. (return default content)
a. ja-JP
b. ja
c. (empty tag or other default content)

5. (default)
a. ja-JP
b. ja
c. und

----

Wildcard values in an extended language range are supposed to match any 
value
=>
Wildcard values in an extended language range match any value

----

Add

      3.3.x. Distance Metric Lookup

Distance metric lookup is performed by producing an ordered list of 
filtered results as specified in 3.2.2, then returning the first item.

----

Mark

P.S. I still think that the extended range lookup doesn't quite work, 
but I'll send that in a separate message.

Addison Phillips wrote:

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