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

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 03 Apr 2005 21:22:17 +0200

On 13:26 03/04/2005, Debbie Garside said:
>Hi Miska
>
>You wrote:
>
> > This is the second time you've used the word "concise"
> > in a way that is unfamiliar to me.  Please clarify what
> > you mean by it.
>
>My meaning is in the strict English sense, as taken from the OED, "giving a
>lot of information clearly but in few words".
>
>In this instance I feel that date as opposed to year is more
>precise/concise... (precision is also top of my agenda) however, as
>previously stated, everything is up for discussion and if there is a clear,
>valid reason for having just "year" I am very interested.

Misha,
date includes year. precision is relative. There are cases where date is 
needed (for example to sort standards, or "first come first serve" 
cases).  There are cases where year is enough. And is more consise as well 
as more precise due to the errors the date treatment can introduce.

For example the date depends on a format, the year not. The date is often 
on 4 bytes, the year can be on 2 or less. If the date is presented with an 
appropriate ascii format, the year is part of it and you have 2 information 
for the digital cost of one, etc. If you list the year first, month and day 
in digits you also get yourself a precise sorting order. If you concatenate 
the and may be a part of a unique string, you have a unique ID you can then 
scramble with an MD5 to obtain a unique stable 32 bytes anonymous ID 
suitable for a random sorting or protection. This is a way to get 3, 4, 5 
or more information one shot. "consise" seems therefore the most 
appropriate word.

As many noted in term of size of a base (which is very different from 
resulting traffic generated by an application) we are not concerned by the 
size but by the apparent complexity of access translating in delays, 
added/biased noise, time, simplisity, surety, security and flexibility of 
update and access, risks of error, database consistency, versatility and 
independence from formats, % availability, involved costs, etc.. So 
conciseness is a complete thinking, including data collection, management 
and dissemination processes, openess, delays and costs. This is precisly 
the issue here.

Debbie is here working one of the most important issue. This is why I do 
not think we can reach anything final before having read what the ISO 639 
group comes with on the matter.

jfc

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

---

From: "Peter Constable" <[email-masked]>
Date: Sun, 3 Apr 2005 22:35:14 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of John Cowan

> > If default script is going to be in the registry, its behavior needs
to
> > be specified in the draft and in the matching draft, and someone
needs
> > to do the expert work of deciding which languages have a "default"
> > script and which do not.
> 
> I think this is out of scope, and only going to get worse with ISO
639-3.
> Let's just not go there.

+1

Peter Constable

---

From: "Addison Phillips" <[email-masked]>
Date: Mon, 4 Apr 2005 09:15:38 -0700

The Recommended Prefix field is rather tightly defined in the draft. If we're going to change the semantics of the field, then we should discuss exactly how, not just change the name.

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Frank Ellermann
> Sent: samedi 2 avril 2005 19:20
> To: [email-masked]
> Subject: [Ltru] Re: Registry in record-jar format
> 
> Doug Ewell wrote:
> 
> > That adds new fields "Deprecated," "Name_Changed," and
> > "Former_Value," which aren't mentioned anywhere in the draft,
> 
> Maybe one new field "Comment" is better than separate fields
> "Depecated" + "Name_Changed" + "Former_Value".
> 
> Please don't mention any former value like NH, if it's not more
> in the registry.  Don't mention CS as former value for CZ or as
> former value for SK.  Any "Former_Value" is like a pointer to a
> deprecated tag, the inverse of "Canonical".  This won't work in
> a case like the old CS.
> 
> > I've changed "Canonical_Value" to "Canonical" and
> > "Recommended_Prefix" to "Prefix,"
> 
> I like it.  I'd like "Related" instead of "Prefix" even better,
> if that's the way to get a "default script" for some languages.
> Otherwise "Prefix" is fine.
> 
> Do we need the "redundant" entries ?  As the name says they are
> really redundant.
>                            Bye, Frank
> 
> 
>

---

From: "Addison Phillips" <[email-masked]>
Date: Mon, 4 Apr 2005 09:21:54 -0700

I oppose default script, as do, I believe, a number of others, as unworkable in practice.

Addison

Addison P. Phillips

> Behalf Of Doug Ewell
> Sent: dimanche 3 avril 2005 10:08
> To: LTRU Working Group
> Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:
> 
> Did we have consensus on default script?  I remember a lot of
> discussion, but no agreement.
> 
> If default script is going to be in the registry, its behavior needs to
> be specified in the draft and in the matching draft, and someone needs
> I'm not sure.  I don't use them myself, except as an informative note in
> my validator, as shown with example "zh-Hans":
> 
> > Subtag 1: zh
> > Language subtag: Chinese (registered 2004-07-06)
> >
> > Subtag 2: Hans
> > Script subtag: Han (Simplified variant) (registered 2004-07-06)
> >
> > RFC 3066 registered description: simplified Chinese (registered
> > 2003-05-30)
> 
> -Doug Ewell
>  Fullerton, California
>  http://users.adelphia.net/~dewell/
> 
> 
>

---

From: "Addison Phillips" <[email-masked]>
Date: Mon, 4 Apr 2005 13:23:22 -0700

See below.

Addison P. Phillips

> From: John Cowan [mailto:[email-masked]]
> Sent: lundi 4 avril 2005 13:03
> To: Addison Phillips
> Cc: [email-masked]
> 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:

/*@[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"       [email-masked]

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 4 Apr 2005 14:17:05 -0700

Hi,

Relative to 'RFC 2616' matching rules below:

It would be well to _explicitly_ address the impact of RFC3066bis
matching rules on the recently published standards-track RFC 3866 
"Language Tags and Ranges in the LDAP" (July 2004).  If directory
entries and/or directory attributes are returned 'incorrectly' by
following RFC3066bis versus RFC3066, then this will have a visible
impact on many enterprise applications.

And to answer the immediate criticism, no I don't know the precise
text to be added.  Perhaps Kurt Zeilenga (editor of RFC 3866) can
comment?  I copied him on this reply.

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]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Addison Phillips
Sent: Monday, April 04, 2005 4:23 PM
To: John Cowan
Cc: [email-masked]
Subject: RE: [Ltru] Re: Registry in record-jar format

See below.

Addison P. Phillips

[Addison Phillips] 

Agreed. 

[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

[Addison Phillips] 

Find all content in need of retagging with a script in my Traditional
Chinese document using XPath:

/*@[lang="zh-!-TW"]
[Addison Phillips] 

[Addison Phillips] 

Agreed. 
[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.

---

From: "Peter Constable" <[email-masked]>
Date: Mon, 4 Apr 2005 13:41:28 -0700

On

> I have yet to receive any comments on my proposed alternative
> (not replacement) matching algorithm...

I like the basic idea. There are details that need further
consideration, though, as Addison has pointed out.

Peter Constable

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 5 Apr 2005 12:11:24 -0700

Duh, location:

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

(or .txt or .xml)

Addison

Addison P. Phillips

> From: Addison Phillips
> Sent: lundi 4 avril 2005 13:23
> To: 'John Cowan'
> Cc: [email-masked]
> I believe it is, although not this specific example. See http://www.inter-
> locale.com/ID/draft-ietf-ltru-matching-00.html#extrange
> 
> >
> Only generative tags in RFC 3066 (i.e. those with only two possible
> subtags) are guaranteed to work with RFC 2616 defined matching.
> >
> > --

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 5 Apr 2005 13:01:05 -0700

No, I'm pretty sure I don't want to say %x10 :-). I just typed ahead rather quickly to get the framework into place and haven't looked at it closely yet.

Your tips are very much appreciated.

Addison

Addison P. Phillips

> Sent: mardi 5 avril 2005 12:52
> To: [email-masked]
> Addison Phillips wrote:
> > Whups.
> <g>  Are you sure that you want to mention \n %x10, and if you
> are sure, how about %x0A or %d10 ?  I really thought that it's
> more or less 2822 compatible, and then you'd have CrLf, not Lf.
> 
> How about: ...separated by a line "%%" ?
> Or if you want ABNF:  ...seaparated by a line "%%" CRLF.
> 
> Just copy what you need from RfC 2234bis (LF, CRLF, and LWSP
> line folding instead of the ugly "\" line continuations).
> 
> Google says that "record-jar" is based on RfC 822, and then
> it's CRLF and folding, not LF and "\".  Thanks for the sneak
> preview... ;-)
>                        Bye, Frank
> 
> 
>