Subject: [Ltru] RE: Various comments from Mark

From: "Addison Phillips" <[email-masked]>
Date: Mon, 5 Dec 2005 09:30:29 -0800

Comments follow...

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: Mark Davis [mailto:[email-masked]]
> Sent: Monday, December 05, 2005 3:55 AM
> To: Martin Duerst
> Cc: Addison Phillips; John.Cowan; [email-masked]
> Subject: Re: Various comments from Mark
> 
> Good comments. Responses below.
> 
> Martin Duerst wrote:
> 
> > Hello Mark, others,
> >
> > I have taken the liberty to change the subject.
> >
> > My personal comments, as a technical contributor,
> > below.
> >
> > At 11:39 05/12/03, Mark Davis wrote:
> > >    more granular matching scheme
> > >
> > >=>
> > >
> > >    more fine-grained matching scheme
> >
> > I wanted to complain about not knowing which
> > way 'granular' goes several times. Thanks for
> > proposing a good solution.
[Addison Phillips] 

Done.
> >
> > >=====
> > >
> > >    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]
> >
> > great fix
[Addison Phillips] 

The idea that it is a "set" is useful, though, as users working with filtering at least should be thinking in terms of sets. Made the change, though.
> >
> > >=====
> > >
> > >    a case insensitive manner
> > >
> > >=>
> > >
> > >    a case-insensitive manner
> > >    [missing hyphens in compound adjectives]
> >
> > ok
[Addison Phillips] 

Replaced three occurrences.
> >
> > >=====
> > >
> > >    Implementations might also wish to use semantic information
> external
> > >
> > >=>
> > >
> > >    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.
[Addison Phillips] 

I dislike putting lots more normative language into the text of an advisory nature. A lot of the conditional text in the document (and I agree that there is a substantial amount of it) covers implementation-specific choices that can be made. Using gobs of normative text for this is questionable.

This particular instance I changed.
> >
> > >=====
> > >
> > >    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.
> >
> > ok
[Addison Phillips] 

Done.
> >
> >
> > >=====
> > >
> > >    Implementations or protocols sometimes might wish to use more
> > >    sophisticated weights
> > >
> > >=>
> > >
> > >    Implementations or protocols MAY use more sophisticated weights
> >
> > same as above for MAY
[Addison Phillips] 

This is problematic because it covers both types of uses for a conditional: it describes an implementation choice (not suitable for normative text) and it gives permission for doing it (very suitable). I changed the sentence more radically, dividing the two uses, so that it reads:

<t>Implementations or protocols MAY vary the scoring used overall or for specific values. For example, sometimes it might make sense to use more sophisticated weighting that depends on the values of the corresponding elements. Thus, depending on the domain, an implementation might give a small distance to the difference between closely related subtags (or treat certain values as equal). Some examples of closely related subtags might be:</t>> >
> > >=====
> > >
> > >    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.
> >
> > I'm okay to use "language range wildcard", but then please
> > make sure this is used consistently.
[Addison Phillips] 

Agreed (with Martin) about using it consistently if we use it at all. Previously we called it the "special language range", but this doesn't make sense once we consider its use in extended language ranges.....
> >
> > >    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).
> >
> > please avoid conditionals:
> > "(or the same request might produce widely varying results)"
> > =>
> > "(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).
[Addison Phillips] 

Notice the problematic "must" in there? In putting in this change, I removed it. Note the wildcards really should be plural here, so the sentence now reads:

--
Since only one item can be returned for any given lookup request, wildcards in a language range have to be processed in a predictable manner or the same request will produce widely varying results.
--

[[ Removed text here sent under separate cover ]]
> > >
> > >    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
> >
> > 'are supposed to' doesn't sound very spec-like.
> 
> Wildcard values in an extended language range are to match...
[Addison Phillips] 

I would normally say "wildcard values... match", but in this case we're about to say that they are treated differently and that they do NOT match. Hence the "are supposed to". I changed it to say the more "speclike" "wildcard values normally match" instead.
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru