Subject: RE: [Ltru] The special status of i-default in lookup

From: "Addison Phillips" <[email-masked]>
Date: Thu, 1 Dec 2005 15:00:47 -0800

I've done my best to edit in both (Martin's version of) John's suggestion below and (Martin's version of) Harald's suggestion regarding implementation. I added Harald's text to Section 3.1 "Choosing Types of Matching".

The modified version is now hosted as "Editor's Copy" on inter-locale.com. See:

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

I made a few other edits as well, mostly cleanup of the English and bugfix. Any comments before I submit this?

The diff, by the way, can be viewed using this URI:

http://tinyurl.com/83cge

(or, if you prefer, the full URI follows)

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.txt&url2=http://www.inter-locale.com/ID/draft-ietf-ltru-matching-08.txt

Addison

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Duerst
> Sent: 2005年11月23日 19:20
> To: John.Cowan; [email-masked]
> Subject: Re: [Ltru] The special status of i-default in lookup
> 
> Hello John,
> 

[Addison Phillips] deleted extraneous text
> 
> I propose to change it to this:
>  > 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, or it might be labeled as i-default [RFC 2277].
> 
> 
> Regards,    Martin.
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Fri, 02 Dec 2005 18:23:31 +0900

At 08:00 05/12/02, Addison Phillips wrote:
 >I've done my best to edit in both (Martin's version of) John's suggestion
 >below and (Martin's version of) Harald's suggestion regarding
 >implementation. I added Harald's text to Section 3.1 "Choosing Types of
 >Matching".
 >

[co-chair hat (mostly) off]
I have been reading 07.txt in detail, and am about half through.
I plan to finish and write things up over the weekend.

[co-chair hat on]

I very much encourage anybody else to also send comments on
this draft. I'd propose that you wait another few days for
another submission.

Regards,   Martin.

---

From: Mark Davis <[email-masked]>
Date: Fri, 02 Dec 2005 18:39:23 -0800

more granular matching scheme

=>

    more fine-grained matching scheme

=====

    the set of language ranges in a language priority list

=>

    the list of language ranges in a language priority list
    [list, since it is ordered]

=====

    a case insensitive manner

=>

    a case-insensitive manner
    [missing hyphens in compound adjectives]

=====

    Implementations might also wish to use semantic information external

=>

    Implementations MAY use semantic information external

=====

    private-use subtags MAY be specified in the language range and MUST
    NOT be ignored when matching.

=>

    Private-use subtags MAY be specified in the language range and MUST
    NOT be ignored when matching.

=====

    Implementations or protocols sometimes might wish to use more
    sophisticated weights

=>

    Implementations or protocols MAY use more sophisticated weights

=====

    The language range "*" matches any language tag. In the lookup
    scheme, this language range does not convey enough information to
    determine which content is most appropriate. 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.

=>

    The language range wildcard "*" matches any language tag. Since only
    one item can be returned for any given lookup request, the wildcard
    must be processed in a predictable manner (or the same request might
    produce widely varying results). Where more than one piece of
    content would be returned, then the implementation MUST specify the
    method used to determine the result.

    For example, it could specify that if "*" is the only range in the
    language priority list, it matches the default content, while if "*"
    is followed by other language ranges, it is skipped.
    [2nd sentence is replaced by better language (copied from a few
    paragraphs below). Method transformed to example, since it should
    not be normative]

=====

    Wildcard values in an extended language range are supposed to match
    any value that occurs in that position in a language tag. Since only
    one item can be returned for any given lookup request, the wildcards
    must be processed in a predictable manner (or the same request might
    produce widely varying results). Thus, for each range in the
    language priority list, the following rules must be applied to
    produce a basic language range for use in the fallback mechanism

    ...*
    Figure 10: Extended Language Range Fallback Example *

=>

    Wildcard values in an extended language range are supposed to match
    any value that occurs in that position in a language tag. Since only
    one item can be returned for any given lookup request, the wildcards
    must be processed in a predictable manner (or the same request might
    produce widely varying results). Where more than one piece of
    content would be returned, then the implementation MUST specify the
    method used to determine the result.
    [The method supplied in the document doesn't match reasonable user
    expections, as stated earlier. Since we can't agree, leave it up to
    the implemention.]

=====

Addison Phillips wrote:

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

---

From: Martin Duerst <[email-masked]>
Date: Mon, 05 Dec 2005 17:56:04 +0900

Hello Mark, others,

I have taken the liberty to change the subject.

My personal comments, as a technical contributor,
below.

 >    more fine-grained matching scheme

I wanted to complain about not knowing which
way 'granular' goes several times. Thanks for
proposing a good solution.

 >    [list, since it is ordered]

great fix

 >    [missing hyphens in compound adjectives]

ok

 >    Implementations MAY use semantic information external

I also didn't like 'might' (there are overall still too many
conditonals in the text), but I'm not totally sure increasing
the number of MAYs is a good thing. But it's probably okay here.

 >    NOT be ignored when matching.

ok

 >    Implementations or protocols MAY use more sophisticated weights

same as above for MAY

 >    The language range wildcard "*" matches any language tag.

I'm okay to use "language range wildcard", but then please
make sure this is used consistently.

 >    Since only
 >    produce widely varying results).

please avoid conditionals:
"(or the same request might produce widely varying results)"
=>
"(otherwise the same request will produce widely varying results)"

 >    Where more than one piece of

'Where', 'would', and 'then' don't make a reasonable sentence for me.
More general, the paragraph starts with "Since only one item can be
returned", so then speaking about more than one piece is confusing.

 >    Wildcard values in an extended language range are supposed to

'are supposed to' doesn't sound very spec-like.

 >    match
 >    content would be returned, then

Again, the 'then' doesn't work for me.

 >    the implementation MUST specify the

Regards,   Martin.

---

From: Mark Davis <[email-masked]>
Date: Mon, 05 Dec 2005 03:54:31 -0800

Good comments. Responses below.

> "(otherwise the same request will produce widely varying results)"

Agree:

Since only one item can be returned for any given lookup request, the 
wildcard must be processed in a predictable manner (otherwise the same 
request will produce widely varying results).

> returned", so then speaking about more than one piece is confusing.

How about:

Where the use of a wildcard would cause matches with two different 
pieces of content, the implementation MUST specify the method used to 
choose between them. For example, the implementation could specify that 
the content tagged with the alphabetically-least language tag is returned.

> 'are supposed to' doesn't sound very spec-like.

Wildcard values in an extended language range are to match...

> Again, the 'then' doesn't work for me.

Repeating from above:

Since only one item can be returned for any given lookup request, the 
wildcard must be processed in a predictable manner (otherwise the same 
request will produce widely varying results). Where the use of a 
wildcard would cause matches with two different pieces of content, the 
implementation MUST specify the method used to choose between them. For 
example, the implementation could specify that the content tagged with 
the alphabetically-least language tag is returned.