[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ltru] Re: Registry in record-jar format



Duh, location:

http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html

(or .txt or .xml)

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: Addison Phillips
> Sent: lundi 4 avril 2005 13:23
> To: 'John Cowan'
> Cc: ltru at ietf.org
> Subject: RE: [Ltru] Re: Registry in record-jar format
> 
> See below.
> 
> Addison P. Phillips
> Globalization Architect, Quest Software
> Chair, W3C Internationalization Core Working Group
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> > -----Original Message-----
> > From: John Cowan [mailto:jcowan at reutershealth.com]
> > Sent: lundi 4 avril 2005 13:03
> > To: Addison Phillips
> > Cc: ltru at ietf.org
> > Subject: Re: [Ltru] Re: Registry in record-jar format
> >
> > Addison Phillips scripsit:
> >
> > > Answer: Yes, it is a problem, since users might have to specify two
> > > ranges or may get results inconsistent with their expectations. For
> > > example, the range "zh-TW" does not match the tag "zh-Hant-TW" using
> > > strict 3066 matching rules.
> >
> > Just a terminological note: I think these should be called HTTP or RFC
> > 2616
> > matching rules, since RFC 2616 is the true and authoritative source for
> > them.
> [Addison Phillips]
> 
> Agreed.
> 
> >
> > > i. "Extended Range Matching" is an extension of RFR in which "missing"
> > > subtags are considered to be (or are expanded to be) wildcards. So
> > > "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" and
> > > "de-AT-1901", not to mention "de-Latg-NA-1901".
> >
> > I think this should be mentioned in the matching I-D.
> [Addison Phillips]
> 
> I believe it is, although not this specific example. See http://www.inter-
> locale.com/ID/draft-ietf-ltru-matching-00.html#extrange
> 
> >
> > > NB> Probably we need to extend this scheme to allow users to specify
> > > that they do NOT want a specific field to be filled in. For example
> > > "de-!-1901" would match only "de-1901" and not a tag such as
> > > "de-Latn-1901".
> >
> > I'd like to see a use case for this (not involving boont).
> [Addison Phillips]
> 
> Find all content in need of retagging with a script in my Traditional
> Chinese document using XPath:
> 
> /* at [lang="zh-!-TW"]
> >
> > > ii. "Lookup" is the opposite of matching, in which subtags are removed
> > > from the tag rather than the range (i.e. locale-style) to fill in all
> > > slots in a dataset. This matches a very different content set.
> >
> > This too should be mentioned.
> [Addison Phillips]
> 
> Being added. Mark supplied text that I haven't had time to insert.
> >
> > > iii. "Scored Matching" was proposed by John Cowan and produces content
> > > with a range of scores, allowing the content to be filtered by
> choosing
> > > a "quality level" (my words) for the match. The user can set a
> threshold
> > > for matching, presumably.
> >
> > As should this.
> [Addison Phillips]
> 
> Agreed.
> >
> > > The problem here is that matching cannot be as simple as it was under
> > > RFC 3066 and still capture all possible cases.
> >
> > This is badly stated.  Only matching of predefined tags in RFC 3066
> > captures
> > all cases.
> [Addison Phillips]
> 
> It is badly stated. But I'm not sure your version captures the nuances
> either. Perhaps:
> 
> Only generative tags in RFC 3066 (i.e. those with only two possible
> subtags) are guaranteed to work with RFC 2616 defined matching.
> >
> > --
> > Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
> > Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
> > Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy,
> > hoopsa!
> >   -- Joyce, Ulysses, "Oxen of the Sun"       jcowan at reutershealth.com


_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.