Subject: [Ltru] John Cowan's comments on matching-10

From: John Cowan <[email-masked]>
Date: Wed, 1 Mar 2006 21:39:56 -0500

My comments, mostly purely editorial:

Section 1, graf 4, just replicates the TOC and should be removed.
Or if you want to keep it, make it explicitly refer to "Section 2",
"Section 3", and "Section 4".

Section 2, graf 3:  for "vary to match their application" read "vary
in accordance with their application".  This avoids confusion with the
technical sense of "match".

Section 2.1, first sentence, is true only of filtering, not of lookup,
and is "semantic" anyhow.  Just drop it.

Section 2.2, first sentences, is about basic LRs but is in the section
on extended LRs.  It doesn't add anything: drop it.

Section 2.2 after ABNF: the MAY there should just be "can"; it's not a
RFC 2119 MAY.

Section 2.2, following graf: remove "(which matches the default content)"
which is true only in lookup.

Section 2.3, last sentence: for "remain" read "remaining".

Section 3, graf 3: for "different ... than" read "different ... from".

Section 3.2, graf 2: for "the language range" read "each language range
in the language priority list".

Section 3.2, graf 3: merge the last graf with this one, and put
"unordered" before "ordered".

Section 3.2.2, graf 4:  for "Extended filtering works, therefore, much
like basic filtering" read "Extended filtering applied to basic ranges
is therefore equivalent to basic filtering."  This is a much stronger
and more definite claim.

Section 3.3, second graf after Fig. 3: proposed rewrite as follows
(using a bulleted list):

	The default content returned when no tag matches the language
	priority list is implementation-defined.  An implementation might,
	for example, return content:

	o	with no language tag;

	o	of a non-linguistic nature, such as an image or sound;

	o	in a particular language designated for the bit of
		content being selected; or

	o	content tagged "i-default" (see [RFC2277]).

	When performing lookup using a language priority list, the
	implementation MUST process each language range in the list
	before returning the default content.

This removes the reference to XML 1.0 and empty xml:lang attributes
(there is no such thing as an empty language tag) in favor of what an
empty xml:lang signals: non-linguistic content.

Section 3.3, second graf after Fig. 4: The last two sentences do not
handle the case where the range "*" appears as the last range in a
language priority list.  I suggest the following replacement for them:

	If the language range "*" is followed by other language ranges,
	it SHOULD be skipped; if no other language ranges follow, the
	default content SHOULD be returned.

Section 3.3, last graf:  for "example" read "possibility".

Section 4.1, graf 3:  this applies only to filtering, and should be
preceded with the words "When filtering,".

Section 4.1, graf 7: for "filtering ... filtered" read "altering
... altered", as this is not the technical sense of "filter" used here.

Section 4.1, last graf: for "matching or filtering" read "matching".

Appendix A, last graf: remove first sentence (about scoring).

-- 
All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part            www.ccil.org/~cowan
that cooks with olive oil, and the part that            www.ap.org
cooks with butter. -- David Chessler                    [email-masked]

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

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 1 Mar 2006 20:50:37 -0800

Responses follow.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: John Cowan [mailto:[email-masked]]
> Sent: 2006?3?1? 18:40
> To: [email-masked]
> Subject: [Ltru] John Cowan's comments on matching-10
> 

This was added previously at Martin's behest. I can add references, although
that seems equally pointless. I'll expunge if there are some "+1" for it.
> technical sense of "match".

Changed to "vary according to their application"
> and is "semantic" anyhow.  Just drop it.

The fundamental point of a basic language range (BLR) is that it is a
prefix. I think we need to identify the fact that a BLR is a prefix to all
tags that match (rather than what an "XLR" does, identifying those subtags
which must be present without regard for interstitial subtags).

But you are right about the tie to filtering, so I changed the sentence to:

--
A "basic language range" describes a user's language preference as a
specific, uninterrupted, sequence of subtags.
--
> on extended LRs.  It doesn't add anything: drop it.

The point was to spell out the difference. I've struggled with the
dissonance here to. Thus I'd suggest we use instead this sentence that
matches the above:

--
Occasionally users will wish to select a set of language tags based on the
presence of specific subtags. An "extended language range" describes a
user's language preference as an ordered sequence of subtags.
--
> Section 2.2 after ABNF: the MAY there should just be "can"; it's not a

Done.
> which is true only in lookup.

Done.
> Section 2.3, last sentence: for "remain" read "remaining".

Already corrected in my copy :-).
> Section 3, graf 3: for "different ... than" read "different ... from".

Done.
> in the language priority list".

That would be good, but a bit wordy. I elected to make it merely "each
language range".
> "unordered" before "ordered".

I merged the sentences to read:

--
<t>If the language priority list (see <xref target="lists"></xref>) contains
more than one range, the content returned is typically ordered in descending
level of preference, but it MAY be unordered, according to the needs of the
application or protocol. </t>
--
> is therefore equivalent to basic filtering."  This is a much stronger

But one that, alas, isn't true. Extended filtering only works with extended
ranges. "de-de" is a basic range (it is also an extended range). In extended
matching, it matches "de-latn-de". In basic matching it does NOT match that
tag. What is similar is that extended matching works as a prefix matcher.

Your larger meta-comment is correct: the sentence is not correct enough to
live. I changed it to:

--
Much like basic filtering, extended filtering selects content with
arbitrarily long tags that share the same initial subtags as the language
range. In addition extended filtering selects content with any intermediate
subtags unspecified in the language range.
--
> 	o	content tagged "i-default" (see [RFC2277]).

Done, with minor mods:

--
<t>The default behavior when no tag matches the language priority list is
implementation-defined. An implementation might, for example, return
content:<list>

   <t> with no language tag;</t>

   <t>of a non-linguistic nature, such as an image or sound;</t>

   <t>with an empty language tag value, in cases where the protocol permits
the empty value (see, for example, "xml:lang" in <xref target="XML10" />,
which indicates that the element contains non-linguistic content)</t>

   <t>in a particular language designated for the bit of
content being selected; or</t>

   <t>it might select the tag "i-default" (see <xref target="RFC2277"
/>)</t>

</list></t>
--
> 	before returning the default content.

Done.
> empty xml:lang signals: non-linguistic content.

Not mentioning the empty value in XML is a problem, though. It ignores the
problem that not many people know this (see: I point it out above) or that
it is used as the Ultimate Default. And other protocols may wish to
designate the empty value as meaning "root" or "default". Xml:lang is merely
a convenient example.
> 	default content SHOULD be returned.

Pretty close. I exchanged sentence order and expanded (others: please note
that "should" has morphed to "SHOULD":

--
If the language range "*" is followed by other language ranges, it SHOULD be
skipped. If the language range "*" is the only one in the language priority
list or if no other language range follows, the default content SHOULD be
returned.
--
> Section 3.3, last graf:  for "example" read "possibility".

Done.
> preceded with the words "When filtering,".

Yes, although there is a similar point is necessary for lookup. Thus I
rewrote and expanded to:

--
When filtering, the fewer the number of subtags that appear in the language
range, the more content the range will probably match, while in lookup
unnecessary subtags might cause "better", more-specific content to be
skipped in favor of less specific content. For example, the range
"de-Latn-DE" would return content tagged "de" instead of content tagged
"de-DE", even though the latter is probably a better match.
--
> ... altered", as this is not the technical sense of "filter" used here.

I used "altered" and "alterations", fixing the grammer to match.
> Section 4.1, last graf: for "matching or filtering" read "matching".

Done.
> Appendix A, last graf: remove first sentence (about scoring).

It was removed from my copy per Mark's comments previously.

Thanks for these excellent comments.

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 1 Mar 2006 21:00:47 -0800

BTW> Editor's copy online is up-to-date.

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

Addison

Addison Phillips

> From: Addison Phillips [mailto:[email-masked]]
> Sent: 2006?3?1? 20:51
> To: 'John Cowan'; [email-masked]
> Subject: RE: [Ltru] John Cowan's comments on matching-10
> 
> Responses follow.
> 
> Addison
> 
> Addison Phillips

---

From: John Cowan <[email-masked]>
Date: Thu, 2 Mar 2006 00:00:01 -0500

> Responses follow.

+1 to everything not in this reply.

>    <t>it might select the tag "i-default" (see <xref target="RFC2277"

This is good, except that the fifth point does not follow grammatically from
the lead-off.  Change to 'labeled with the language tag with "i-default"' etc.

-- 
Using RELAX NG compact syntax to        John Cowan
develop schemas is one of the simple    http://www.ap.org
pleasures in life....                   http://www.ccil.org/~cowan
        --Jeni Tennison                 <[email-masked]>

---

From: Mark Davis <[email-masked]>
Date: Thu, 02 Mar 2006 07:28:53 -0800

I like the changes. One more nit: needs semicolons either on all the 
non-final list elements or none.

return content:

    with no language tag;

    of a non-linguistic nature, such as an image or sound;

    with an empty language tag value, in cases where the protocol
    permits the empty value (see, for example, "xml:lang" in [XML10]
    (Bray (et al), T., “Extensible Markup Language (XML) 1.0,” 02 2004.)
    <http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.html#XML10>,
    which indicates that the element contains non-linguistic content)

    in a particular language designated for the bit of content being
    selected; or

    it might select the tag "i-default" (see [RFC2277] (Alvestrand, H.,
    “IETF Policy on Character Sets and Languages,” January 1998.)
    <http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.html#RFC2277>)

And it would look better bulleting, IMO.

Mark