Subject: [Ltru] editorial comments on draft-07 (part 2)

From: Martin Duerst <[email-masked]>
Date: Tue, 06 Dec 2005 18:58:56 +0900

[co-chair hat off]

and on we go...

3.1 Choosing a Type of Matching, continued.
- third-to-last para: I find the HTTP example problematic.
   It somehow suggests that is what HTTP says. As Mark has explained,
   it is close to what servers do, but not what the spec says.
   It also ignores the possibility of "300 Multiple Choices"
   responses (see
   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1)
   I'm not exactly sure what to do, probably the best thing is
   to find another example.
- second-to-last para: 'examine the values': What exactly does
   that mean? Maybe change to something like "don't need any
   additional information about any specific subtags".
- dito: "Language Registry Subtag": Please provide a reference
   (to draft-initial, I guess)
- dito, last sentence: simplify to "This simplifies and speeds
   up implementations." (you can add 'greatly' if you want to keep it)
- last para: I think this paragraph should be moved to section 4.

3.2 Filtering
- 1st para: 'arbitrary number' -> 'arbitrarily large number' ?
- 2nd para: '_least_ specific': please add that it is therefore
   shortest
- third bullet: 'in specific range' -> 'in a specific range';
   also, 'range of languages' is similar (but not the same as)
   'language range' (the former being semantics, the later syntax),
   so maybe a different word from 'range' is better.
- 3rd last para: 'would put ... priority order' ->
   'would order the results [by priority]' ?
- last para: 'each language tag to a language range':
   unclear why 'each' on one side, but 'a' on the other side,
   suggest to use 'a' for both
- dito: distance indicated -> distance indicates
- dito, last sentence: 'or it can': what does 'it' refer to?
   maybe 'implementations', but then numbers don't match

3.2.1 Filtering with Basic ...
- There is nothing explaining what happens with language
   priority lists.

3.2.2 Filtering with Extended ...
- 1st para: 'Extended Range Matching scheme': is that the
   terminology we use? The term 'basic matching' is also
   used in this paragraph, but lower case.
- dito: we should first describe how a single extended language
   range matches, and only then go to describe how language
   priority lists are dealt with.

3.2.3 Scored Filtering
- 1st para: 'beneficial' -> 'useful' (beneficial sounds a bit
   too much like we're trying to save the world)
- 2nd para: 'must be canonicalized' -> 'MUST ...' ?
- 3rd para: 'language element': I checked RFC 3066bis, and
   didn't find 'element' at all. Please allign terminology.
- 4th para: 'language-tag' -> 'language tag'
- dito: Thus a pattern ...: merge with following list.
   (if not, then at least change 'a pattern' to 'the pattern')
- "Examples of various tag's distances": "tag's" -> "tags'"
- "might give a small distance to the difference closely related"
   -> "might give a small distance to closely related"
- The paragraph with that sentence, and the examples following,
   seem to turn up in slightly different form in other places.
   Please check if it doesn't make sense to move that topic
   to a general place.
- Region: UM: add a parenthesis at the end of that line

3.3 Lookup
- General: This is a long section, I propose to create some
   subsections, as follows:
   - one for the general stuff at the start
   - one for the discussion of priority lists (in -07 starting
     just before the end of page 15)
   - one for extended language ranges (after what's Figure 8
     in -07)
- 1st para: talk about single language ranges only here,
   about priority lists later.
- "only the closest matching item ...": Add something to say
   that it's returned only if it is less specific.
- "Selection of a graphic containing text": I don't like
   this example, because it is bad accessibility practice.
- after bullet list: "in the Lookup scheme": probably better
   lower-case.
- same para: 'would progressively search': Change to
   "progressively searches"
- There are about 6 cases in the draft where 'zh' turned
   into 'z.', please change back.
- "as with xml:lang in the XML specification":
   - This may be understood to mean use of xml:lang in the
     specification itself. Please clarify.
   - A reference to the XML spec should be added non-normatively.

More to follow tomorrow.     Regards,   Martin. 

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

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 6 Dec 2005 21:42:23 -0800

Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

> ...

Any reference to the registry per se had better not contain a pointer to 
draft-initial.  That document is most emphatically not the registry 
itself (and it says so), and it will be out of date almost immediately 
upon publication, as some of us will be leaning on the Reviewer to make 
six ISO 639-based additions and changes as soon as the registry becomes 
available.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 7 Dec 2005 08:30:34 -0800

Frank Ellermann wrote:
[snip]
> You could (informative reference), but as placeholder for the
> "real" registry it's a dubious idea.
> 
> > How about we reference where it is defined, i.e. RFC 3066bis
> > (draft-registry), Section 3?
> 
> Or use the "real" IANA URL (TBD) of the tag registry, it will
> exist before the matching draft gets an RFC number.  Ideally
> it will be <URL:http://www.iana.org/assignments/language-tags>.
> 

No.  The existing RFC 3066 registry is at the above URL.  The
new SUBtags registry MUST NOT simply overwrite the full tags
registry.  The existing full tags registry should have a note
inserted at the top by IANA stating that it's obsolete (and no 
longer maintained) when the subtags registry is available.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 7 Dec 2005 08:50:37 -0800

Responses below. All extraneous text removed.

Addison

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]]
> Sent: Wednesday, December 07, 2005 3:08 AM
> To: Addison Phillips; LTRU Working Group
> Subject: RE: [Ltru] editorial comments on draft-07 (part 2)
> 
> Comments below. Simple "done"s and "fixed"s are acknowledged and removed.
> 
> 
>  >[Addison Phillips]
>  >Not sure. Kept in place for now.
> 
> I'll probably come back to this on my next read.
[Addison Phillips] 

Please do.
>  >
>  >Note that "shortest" in characters isn't always the least specific.
> 
> Ok, good point.
[Addison Phillips] 

Although I should point out that, given content restrictions in 3066bis, it almost always is. However, the best counter example is that "de-Latf" (7) is "less specific" on some level than "de-DE" (5)....
>  >[Addison Phillips]
>  >Done. Used "set of languages" in place of various range locutions, which
> is
>  >in keeping with the use of LPLs instead of ranges in the schemes.
> 
> I think Mark specifically didn't like 'set', because it's different
> from list.
[Addison Phillips] 

Yes, for ordered lists (such as the LPL), but he didn't say anything in particular about a (potentially unordered) result set, such as described here.
>  >[Addison Phillips]
>  >Changed to read:
>  >A distance metric assigns a numeric value to the comparison of each
>  >language tag to each language range that represents the 'distance'
> between
>  >the two.
>  >--
> 
> I agree that strictly speaking, it's "each", but that's
> usually understood when using "a" (meaning "an arbitrary"),
> and
[Addison Phillips] 

I wanted to emphasize the "pairing" aspect of scored filtering here. The numeric score is assigned to a specific pair of values, which is somewhat less arbitrary.
> 
>  >>>>
> A distance metric assigns a numeric value to the comparison of a
> language tag to a language range that represents the 'distance'
> between the two.
>  >>>>
> 
> in my view really is easier to read than your text.
[Addison Phillips] 

Okay.
>  >[Addison Phillips]
>  >It has different meaning here. I suspect that, with some additional
>  >inspection, I can find the other generic instances and harvest them for
>  >inclusion in Section 4 somewhere.
> 
> Please go ahead, at least with the inspection.
[Addison Phillips] 

Will do.

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 7 Dec 2005 09:23:50 -0800

RTFM. RFC 3066bis says:

--
The new registry MUST be listed under "Language Tags" at http://www.iana.org/numbers.html, replacing the existing registrations defined by [RFC3066] (Alvestrand, H., “Tags for the Identification of Languages,” January 2001.). The existing set of registration forms and RFC 3066 registrations MUST be relabeled as "Language Tags (Obsolete)" and maintained (but not added to or modified).
--

Addison P. Phillips

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> McDonald, Ira
> Sent: Wednesday, December 07, 2005 8:31 AM
> To: 'Frank Ellermann'; [email-masked]
> Subject: RE: [Ltru] Re: editorial comments on draft-07 (part 2)
> 
> Frank Ellermann wrote:
> [snip]

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 7 Dec 2005 14:19:08 -0800

Hi,

Two different things - you're talking about labels in HTML.

Frank gave an actual HTTP URL (which happens to correspond 
one-to-one to the current FTP URL).  

It is exceedingly bad practice to blow away a registry at a 
URL with a different registry with different semantics.

Keep your labels.  But let's behave well about durable URLs.

Cheers,
- Ira

> From: Addison Phillips [mailto:[email-masked]]
> Sent: Wednesday, December 07, 2005 12:24 PM
> To: McDonald, Ira; Frank Ellermann; [email-masked]
> The new registry MUST be listed under "Language Tags" at 
> http://www.iana.org/numbers.html, replacing the existing 
> registrations defined by [RFC3066] (Alvestrand, H., “Tags for 
> the Identification of Languages,” January 2001.). The 
> existing set of registration forms and RFC 3066 registrations 
> MUST be relabeled as "Language Tags (Obsolete)" and 
> maintained (but not added to or modified).
> --
> 
> Addison P. Phillips