Subject: RE: [Ltru] Editorial nits (was: ABNF beautification...)

From: "Addison Phillips" <[email-masked]>
Date: Thu, 28 Jul 2005 16:18:40 -0700

Responses below.

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: Thursday, July 28, 2005 5:30 AM
> To: [email-masked]
> Subject: [Ltru] Editorial nits (was: ABNF beautification...)
> 
> Addison Phillips wrote:
> 
> > The beautified ABNF is posted in an editor's copy:
> 
> ACK.  I don't find the time to read it loud word for word,
> but at least I scanned it (= complete text) visually for
> minor nits:
> 
> ~~~ old ~~~
> field-name = *(ALPHA / DIGIT / "-")
> ~~~ new ~~
> field-name = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
> ~~~ end ~~~
> 
> Verified with Bill's parser.  AFAIK that's what you want:
> 
> A field-name can't be empty, starts with ALPHA, and doesn't
> end with a hyphen.
> 
> Okay, I should have said so earlier, OTOH I did IIRC <gd&r>
[Addison Phillips] 

Your ABNF isn't strictly accurate, since it requires that field names be at least two characters long, although it doesn't actually affect anything to make any of your proposed changes (none of the field names defined violate the rules). I don't see making this particular ABNF (note to readers: this is the ABNF for record-jar format in Section 3.1) less beautiful in order to express 50% of the requirement. How about:

Field-name = ALPHA *(ALPHA / DIGIT / "-")

Or we could go with your previous proposal of listing the file names as strings in the ABNF (ick).

> 
> | Note that the hexadecimal notation MAY have between two and
> | six digits.
> 
> The given XML source allows also one hex. digit, e.g. &#x9;
[Addison Phillips] 

Yes, technically, but the following requirement prevents them from being used in the registry:

--
Characters from outside the US-ASCII repertoire, as well as the AMPERSAND character ("&", %x26) when it occurs in a field-body are represented by a "Numeric Character Reference"
--

All the one-digit items are in the US-ASCII repertoire and thus won't be used.....
> 
> Maybe delete that note, or s/two/one/ (dubious, the source
> also allows more than six hex. digits, e.g. &#x00000026;)
[Addison Phillips] 

But Unicode and ISO/IEC 10646 will never define scalar values > 0x10FFFF. Values with seven or eight digits are like UTF-8 sequences with five or six bytes---possible from a logical point of view, but never used (and, in the case of UTF-8, now actually illegal). The use of the RFC 2119 keyword MAY restricts the length to six. It could say "MUST", of course.

> 
> | records of whose Type has one
> 
> Some upper case Type, many 'Type', maybe s/ Type / 'Type' /g
[Addison Phillips] 

ACK. Also fixed the one occurrence of "Type" to be 'Type'.
> 
> | Long screeds about a particular subtag are frowned upon.
> 
> Rarely I need a dictionary for en2de (often for de2en, that's
> another issue).  It says "fig. coll." for "screed", how about
> s/screeds/comments/ ?
[Addison Phillips] 

'Screed' conveys (auf Englisch) a pejorative sense, but isn't good International English. Changed to "texts".

> 
> | This field MAY appear at most one time
> 
> Are you sure about "MAY at most" ?  I'd say "MUST at most".
[Addison Phillips] 

"MAY at most" means it can be omitted. "MUST at most" means the same thing but possibly conveys the sense of the requirement better. The best is what I changed it to:

--
This field MUST NOT appear more than one time in a record.
--
> 
> |      1.  The region code 'TL' was assigned to the country
> 
> You don't want the "1." here, this list has only one item.
[Addison Phillips] 

Correct. I wanted this to be an indented example. In the XML it is actually <list style="empty">, which is supposed to give that effect (but doesn't). I've changed to style="hanging" to get the proper effect.
> 
> Other sublists at this level use letters, but a sublist only
> with "A." (no "B.") is strange.  Elsewhere you use a bullet
> for lists with only one item.
> 
> The format of the "registration form" in 3.4 is also strange,
> maybe try "artwork" to get something like this:
> 
> ~~~ new ~~~
>    LANGUAGE SUBTAG REGISTRATION FORM
>    1. Name of requester:
>    2. E-mail address of requester:
>    3. Record Requested:
>       Type:
>       Subtag:
>       Description:
>       Prefix:
>       Preferred-Value:
>       Deprecated:
>       Suppress-Script:
>       Comments:
>    4. Intended meaning of the subtag:
>    5. Reference to published description
>       of the language (book or article):
>    6. Any other relevant information:
> ~~~ end ~~~[Addison Phillips] \
[Addison Phillips] 

Um... it is artwork already and looks remarkably like that in both HTML and TXT versions:

--
LANGUAGE SUBTAG REGISTRATION FORM
   1. Name of requester:
   2. E-mail address of requester:
   3. Record Requested:

   Type:
   Subtag:
   Description:
   Prefix:
   Preferred-Value:
   Deprecated:
   Suppress-Script:
   Comments:

   4. Intended meaning of the subtag:
   5. Reference to published description
   of the language (book or article):
   6. Any other relevant information:

                                 Figure 5
--

If you mean the indentations, I added those to make it nicer.
> 
> | Any new registrations submitted after the adoption of this
> | document MUST be rejected.
> 
> Is that necessary ?  IMHO it's obvious.
[Addison Phillips] 

There is a period after the adoption and before publication in which there might be some confusion. This closes that loophole.

> 
> | Subtags of type 'Region' that have a Preferred-Value mapping
> | in the IANA registry (see Section 3.1) SHOULD be replaced
> | with their mapped value.
> 
> Add:  "In rare cases this step has to repeated".
[Addison Phillips] 

Okay. Inserted with slight alteration:

--
<t>Subtags of type 'Region' that have a Preferred-Value mapping 
      in the IANA registry (see <xref target="ianaformat"/>) SHOULD be 
      replaced with their mapped value. Note: In rare cases the mapped value will also have a Preferred-Value.</t>
--
> 
> | Example: The language tag "en-NH"
> 
> s/NH/BU/g and s/VU/MM/g - we want an example visible in the
> registry, not an obsolete case eliminated by the "date A" rule.
[Addison Phillips] 

Okay. Burma/Mynamar isn't necessarily a felicitous combination, but there aren't a lot of examples given the date A/date B rules.
> 
> I don't see the US-ASCII reference proposed by Scott, did you
> forget it ?

[Addison Phillips] 

Nope, didn't forget it. US-ASCII's reference is:

[ISO646]   ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, Information
              technology -- ISO 7-bit coded character set for
              information interchange.", 1991.

And it is referred correctly in the text. A lot of folks tend to see ISO 646 and think ISO 10646...

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 29 Jul 2005 07:53:54 +0200

>> field-name = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
[...]
> Your ABNF isn't strictly accurate, since it requires that
> field names be at least two characters long

The square brackets [...] mean optional, zero or one.

> Field-name = ALPHA *(ALPHA / DIGIT / "-")

Also fine and shorter, but it can end with hyphen(s).

> Or we could go with your previous proposal of listing
> the file names as strings in the ABNF (ick).

That's too late.  You wanted a general format covering
future extension registries.

> --
> Characters from outside the US-ASCII repertoire
[...]

Okay, one hex. digit would be ASCII, forget s/two/one/

>> also allows more than six hex. digits, e.g. &#x00000026;

> But Unicode and ISO/IEC 10646 will never define scalar
> values > 0x10FFFF.

That's what they say today, some years ago it was 31 bits,

UTF-32 still _is_ 32 bits (always in the form 0x00??????),
nothing wrong with leading zeros.  Or I didn't see it in
the linked XML spec. (?)  Of course we don't _need_ these
details, the "two to six" was just something I saw in the
draft - and I wrote my cp858 to UTF-8 converter only last
year, so I'm still looking for all Unicode oddities... ;-)

>> "fig. coll."
[...]
> 'Screed' conveys (auf Englisch) a pejorative sense

Yes, I got the sense without knowing the word, and then I
was curious and looked it up.

>>   6. Any other relevant information:
[...]
>    6. Any other relevant information:
[...]

> If you mean the indentations, I added those to make it nicer.

Yes, thanks.

> [ISO646]   ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991,
[...]
> A lot of folks tend to see ISO 646 and think ISO 10646...

Yes, sorry, I missed that, in another spec. it's different:

| [US-ASCII]
|            American National Standards Institute (formerly United
|            States of America Standards Institute), "USA Code for
|            Information Interchange, X3.4", 1968.
|
|            ANSI X3.4-1968 has been replaced by newer versions with
|            slight modifications, but the 1968 version remains
|            definitive for the Internet.

Some control characters changed or renamed IIRC, irrelevant
for 3066bis, we only need CRLF and SP as found in ABNF.  Bye