Subject: RE: [Ltru] Re: new version posted online

From: "Addison Phillips" <[email-masked]>
Date: Mon, 18 Apr 2005 17:19:24 -0700

Some notes 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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Frank Ellermann
> Sent: lundi 18 avril 2005 16:56
> To: [email-masked]
> Subject: [Ltru] Re: new version posted online
> 
> Addison Phillips wrote:
> 
> > I think there is a diminishing return to ruling out various
> > subtag forms. Why allow '1dr5' and not '1234567'?
> 
> Just to be sure, 1dr5 matches the less subtle DIGIT 3alphanum,
> and it matches DIGIT 3*7alphanum, so it's okay in all discussed
> ABNF versions.  1234567 matches a less subtle 5*8alphanum, and
> it matches a subtle DIGIT 3*7alphanum, also okay.  The subtle
> ABNF and the less subtle ABNF for a variant are equivalent.
[Addison Phillips] 

Something like that.
> 
> Starting with chapter 3 - I like to read ABNF, it's addictive:
> 
> | field-name = *(ALPHA/NUM/%x5F)
> 
> IMHO it's better to enumerate them.  Do we have any convincing
> reasons to use "_" instead of "-" in field names ?  Mail and
> news header field names use "-" (no rule, an observation).
[Addison Phillips] 

No reason. Actually, hyphen-minus would be more in keeping with the spirit of 3066 I suppose.

> 
> You use uppercase for character names everywhere (HYPHEN-MINUS,
> COLON, AMPERSAND, EURO-SIGN), I'm not sure about this style.
[Addison Phillips] 

The names are all Unicode character names. Thankfully we don't have any examples that use Indic zero digits :-). 
> 
> The XML-URl is still the 3rd ed., not the shorter generic URL
> of the latest version: http://www.w3.org/TR/REC-xml/#dt-charref
[Addison Phillips] 

Will correct.

> 
> For an explanation of "folding" you could reference RfC 822,
> but actually the FWS in 2822 is better than the LWSP in 2234bis
> for this purpose.  LWSP allows "empty" lines (trailing blanks),
> we don't need or want this in the registry.  Better _copy_ FWS
> from RfC 2822, we also don't need or want obs-FWS:
> 
>  field-body = *( ASCCHAR / FWS )
>  FWS        = [*WSP CRLF] 1*WSP    ; Folding white space
[Addison Phillips] 

I thought I referenced the right thing (2234bis) for the ABNF itself. Using LWSP is a tad bit obscure. Blank lines in the registry don't hurt anything. Especially if there aren't any. And this ABNF is ultra-tight.
> 
> For 'subtag' you say "MUST only..." enumerating the five types.
> 
> For 'tag' you say "MUST" (gradfathered / redundant) followed by
> a "MUST NOT...".  The "MUST only..." style without "MUST NOT"
> is less verbose.
[Addison Phillips] 

Agreed.
> 
> | Description values are restricted to the Basic Latin and
> | Latin-1 blocks as defined by Unicode [7] (that is, ISO/IEC
> | 10646 character numbers less than U+0100).
> 
> Why this restriction ?  What's wrong with say Zcaron, Yuml, or
> OElig ?  You even have the Euro as example elsewhere.
[Addison Phillips] 

Description is separate from Comment. Comment allows anything. Description is fixed to Latin-1. Various folks wanted that limitation to reference ISO 8859-1, but as a Unicadet I fudged and used Unicode blocks. And saved a reference. 

Limiting to "script = Latn" is messy, since so many characters might be construed to be Latin. Personally, I don't agree with having to have a limitation. Why restrict ourselves unnecessarily?
> 
> | For example: 2004-06-28 represents June 28, 2004, in the
> | Gregorian calendar.
> 
> Once is enough, you have it in Added _and_ Depreated. 
[Addison Phillips] 

Yes, well... I try to be thorough. It might be better to define date values and then say that each of these fields (and File_Date) uses that format.

 But an
> example for Recommended_Prefix where it's defined could be
> useful.  You could say that it's _never_ used for a 'Language',
> like you later say that Suppress_Script MAY _only_ be used for
> a 'Language'.
[Addison Phillips] 

Agreed.
> 
> Some field definitios have a period, others don't.  In "Either
> 'Subtag' or 'Tag'" that results in two unseparated sentences.
[Addison Phillips] 

Will correct.
> 
> I'm not happy with the canonical rules, they have undesirable
> effects for region codes => JFTR, after draft -01. 
[Addison Phillips] 

I'd like to run out of drafts soon and go to LC on schedule. But let's get draft-01 out first.

 But there's
> another STRONGLY in this section.
[Addison Phillips] 

I'll step on the STRONG strongly.
> 
> | Comments
> 
> The examples use "Comment" (singular).  Later there's another
> "Comments".  Quite a lot of examples, maybe you can delete some
> less interesting examples, e.g. either Africa or North America.
[Addison Phillips] 

Intended to blow some away, will do that now. Perhaps we should also move the example registry to an Appendix.

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Apr 2005 16:15:36 +0200

Addison Phillips wrote:

>> equivalent.

Sigh, I give up, the equivalent subtle version is good enough.

After I checked 2234bis 3.5 and 3.10  (Shame on me, I didn't
know that ABNF concatenation comes before alternative - maybe
you could use =/ instead of / in the subtle 'variant' ABNF ;-)

If I got it right (2234bis 3.3) that would be:

 variant         =  ALPHA (4*7alphanum)
 variant         =/ DIGIT (3*7alphanum)

Or with 2234bis 3.5 groups instead of 3.3:

 variant         =  ( ALPHA 4*7alphanum )
                  / ( DIGIT 3*7alphanum )

JFTR the equivalent "less subtle" variant in this context:

 variant         =  5*8alphanum 
                  / ( DIGIT 3alphanum )

                    Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Apr 2005 17:07:57 +0200

Addison Phillips wrote:

>> Do we have any convincing reasons to use "_" instead of "-"
>> in field names ?  Mail and news header field names use "-"
>> (no rule, an observation).

> with the spirit of 3066 I suppose.

With Doug 3:0 for HYPHEN-MINUS (a.k.a. 'dash' in 2234bis)

> The names are all Unicode character names.

The x-refs in U40M030411.lst use lower case:

| 2010    HYPHEN
|         x (hyphen-minus - 002D)
|         x (soft hyphen - 00AD)

> Thankfully we don't have any examples that use Indic zero
> digits :-).

Checking, yes, thanks.  One of the many advantages of Unicode,
it's impossible to have a worse idea that still makes sense.

 [yuml but no Yuml] 
> Various folks wanted that limitation to reference ISO 8859-1,
> but as a Unicadet I fudged and used Unicode blocks.

The but-part is clear, I don't get the premise:  If now Doug or
later IANA are forced to filter "official" descriptions found
in the source standards against Latin-1 it could be a problem.

What if the only official description uses Latin-0 characters
not covered by Latin-1 ?  Yuml is on the letterbase list with
characters required for French, Jefsey wil kill us if that's
true and we exclude it without good reasons:

http://www.eki.ee/letter/chardata.cgi?lang=fr+French&imgonly=on&script=latin

> Limiting to "script = Latn" is messy

True, why not simply copy whatever the official source says ?
Let them do their own limiting.

> Personally, I don't agree with having to have a limitation.
> Why restrict ourselves unnecessarily?

Add me.  Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Apr 2005 20:16:37 +0200

Addison Phillips wrote:

  [folding]
>> the FWS in 2822 is better than the LWSP in 2234bis for this
>> purpose.  LWSP allows "empty" lines (trailing blanks), we
>> don't need or want this in the registry.  Better _copy_ FWS

> I thought I referenced the right thing (2234bis) for the ABNF
> itself. Using LWSP is a tad bit obscure. Blank lines in the
> registry don't hurt anything. Especially if there aren't any.
> And this ABNF is ultra-tight.

That's true, but the reasons _why_ it's true are interesting,
it's a feature of the "%%" in the record-jar format.

| Example: one two  three

Some obvious ways to fold this example are:

| Example: one
|  two  three

| Example: one
|  two
|   three

Now I use _ for SP in the same examples:

| Example:_one
| _two__three

| Example:_one
| _two
| __three

So far all is fine, now I fold __three at the second SP:

| Example:_one
| _two_
| _three

The trailing SP in the line _two_ won't survive simple editors
and other tools not expecting trailig spaces, but that's no
problem.

Now I fold all SP wherever they are:

| Example:
| _one
| _two
| _
| _three

Still okay, but after a simple editor or another tool removed
the trailing space you'd get:

| Example:
| _one
| _two
|
| _three

In something like mail or news the line _three would now be
the first line of the body.  In a format where empty lines
instead of %% terminate entries the entry would be broken.

With LWSP the latter is possible, with FWS it's not.  But as
you said in reality we have %% and this is all irrelevant ;-)

                       Bye, Frank