Subject: [Ltru] Matching: choice of schemes

From: Martin Duerst <[email-masked]>
Date: Wed, 16 Nov 2005 18:43:28 +0900

[This is a technical contribution, mostly motivated
by my long experience with how other WGs use specs.]

The section on choice of matching schemes has been moved
closer to the front of the document. This is good.

But there are some, in many ways serious, problems. I think
they are serious because in many ways, this is the most
important section of this draft: Other WGs creating protocols
and formats, and application designers, ideally should be
able to go to that section, read it, and then reference
the section that they have identified as being the most
appropriate for their usage case, and be done with it.
Of course, we as experts hope that others will study this
draft in detail, but that's generally not going to happen.

What will happen most often is A) a WG or so just picks a
scheme based on their first impression, because they want
to move on, or B) a WG gets entangled into long discussions
because it's not really clear from our draft what is best
for them.

While I understand that there is a limit in the advice we
can give, I think we definitely can and should try our best
to make sure we give as much advice as we can, and make it
as clear as possible.

So here are my specific comments:

First, make sure we have a (sub)section entitled
"Choice of language matching scheme" (or some such), so
that this is easy to find.

Second, make sure we discuss all alternatives. In particular,
currently the choice between 'filtering' and 'lookup' is
given, but the choice between basic and extended isn't
discussed at all.

Third, try to use as definitive and precise wording as possible.
Ideally, if we have five different schemes, then we would
have five paragraphs, each clearly mentioning the conditions
and circumstances for chosing that scheme.

Fourth, clearly separate the choice of matching scheme from
advice like "and you may also think about doing this and that
on top of it". This is particular applies to what is currently
(in Addison's draft draft) the last paragraph just before
section 3.1 (talking about nn/nb/no and zh-CN/zh-Hans).
This paragraph only confuses people trying to make their
choice. In may view, the best thing we could do with this
paragraph is to move it to a section entitled something
like "Limitations of Matching Schemes" or so, somewhere
in the "Others" section.

Fifth, the text currently mostly uses the words "implementer"
and "implementation". Similar to "application", the first
impression this gives is that it's about implementations of
(end user) applications. However, our first and foremost
concern should be with what is generally called
"protocol designers" or "spec writers", and we should chose
wording that makes this clear.

Regards,    Martin. 

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

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 16 Nov 2005 11:11:51 -0800

> wording that makes this clear.

I did wordsmithing to address this to the extent possible. The stem "implement..." appears frequently in the "Length" section, where it is roughly comparable to draft-registry's text.

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture.

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 16 Nov 2005 11:49:38 -0800

> that this is easy to find.

Done.
> given, but the choice between basic and extended isn't

It is kind of discussed inside the section on extended and in the section on extended language ranges. Suggest some text to put into "choice"?
> and circumstances for chosing that scheme.

We have four different schemes:

- Basic Filtering (for use with basic ranges)
- Extended Filtering (for use with extended ranges)
- Scored Filtering (for ordered lists)
- Lookup

I have provided suggested text in draft-06 that does what you want with regard to describing the choices. Here it is:

--
<t>Filtering can be used to produce a set of results (such as a collection of documents). For example, if using a search engine, one might use filtering to limit the results to documents written in French. It can also be used when deciding whether to perform some processing that is language sensitive on some content. For example, a process might cause paragraphs whose language tag matched the language range "nl" to be displayed in italics within a document.</t>

<t>This document describes three types of filtering:
   <list style="numbers">

   <t><xref target="basicMatch">Basic Filtering</xref> is used to match content using basic language ranges<xref target="basicRange"></xref>. It is compatible with implementations that do not produce extended language ranges.</t>

   <t><xref target="extMatching">Extended Range Filtering</xref> is used to match content using extended language ranges<xref target="extrange"></xref>. Newer implementations SHOULD use this form of filtering in preference to basic filtering.</t>

   <t><xref target="scoredMatching">Scored Filtering</xref> produces an ordered set of content using either basic or extended language ranges. It should be used when the quality of the match within a specific language range is important, as when presenting a list of documents resulting from a search.</t>

   </list></t>

<t><xref target="lookup">Lookup</xref> is used when each request MUST produce exactly one piece of content. For example, a Web server might use the Accept-Language HTTP header to choose which language to return a custom 404 page in: since it can return only one page, it must choose a single item and it must return some item, even if no content matches the language ranges supplied by the user.</t>
--

> like "Limitations of Matching Schemes" or so, somewhere

I've reached the limit of what can be done, I think, without a clean draft. Propose (moving or additional) text for draft-07, okay?

Addison

Addison P. Phillips

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Duerst
> Sent: 2005年11月16日 1:43
> To: LTRU Working Group
> Subject: [Ltru] Matching: choice of schemes
>

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 16 Nov 2005 17:23:29 -0800

Cool. I like specific comments and don't mind it if you don't like my proposals (made in the dark of night, as it were: I'm not too fond of the quoted text myself). We'll make better progress by working from some text, tho'.

The text has gone up to the ID editor or you can read it on inter-locale (I made one last round of error corrections/additions/emendations).

Note that I'm not producing a diff for this version: the differences are too vast, given wholesale moving of text.

Addison

Addison P. Phillips

> From: Harald Tveit Alvestrand [mailto:[email-masked]]
> Sent: 2005年11月16日 17:02
> To: Addison Phillips; Martin Duerst; LTRU Working Group
> Subject: RE: [Ltru] Matching: choice of schemes
> 
> 
> 
> --On 16. november 2005 11:49 -0800 Addison Phillips
> <[email-masked]> wrote:
> 
> > I have provided suggested text in draft-06 that does what you want with
> > regard to describing the choices. Here it is:
> 
> I've got issues with almost every single paragraph in the text you propose.
> But I think the -06 reorganization has exposed these issues much more
> clearly than the previous versions - which is very good. I'll comment on
> -06 after publication.
> 
>