Re: [Ltru] (editor response) Review of 4646bis-10, sections 1 to 3.4

[Addison Phillips <[e-mail]>]

Notes follow indicating incorporation into draft-11 editor's copy. After 
I figure out the insta-submit process and do other housekeeping, look 
for it in draft-11. My disposition of these edits as follows.

John Cowan wrote:
> Yet another freakin' de novo review of 4646bis draft 10, sections 1
> through 3.4.  More review will follow.  The following two changes are
> substantive:
> 
> 1) I suggest adding this to 2.2.6 (extensions) after the first sentence:
> 
>         They are intended to identify information which is commonly used
>         in association with language tags but is not part of language
>         identification.

Done, with a minor edit. Paragraph reads:

--
Extensions provide a mechanism for extending language tags for use in
various applications. They are intended to identify information which is
commonly used in association with languages or language tags, but which
are not part of language identification. See <xref
target="extensions"></xref>. The following rules apply to extensions:
--

> 
> 2) In 3.1.2, I'd prefer to say that implementations MUST rather than
> SHOULD ignore undefined fields in the registry.  There is no reason why
> implementations should not be required to be liberal in what they accept.

While I agree with the sentiment, you and I accept Stephane's reading 
later in this thread. Not incorporated.

> 
> 
> The remaining changes are all editorial:
> 
> In 2.2, the term "code" is defined to refer to a value defined in an
> external standard.  We should, pervasively throughout the document,
> change this to "code element", which is proper ISO terminology.  (For ISO,
> "code" means the whole list.)

Argh. I tried to do this, but:

1. The names of the ISO standards use the word "code" or "codes"
2. The quote from ISO 639RA/JAC uses the word "code"
3. Using the term "code element" was really REALLY ugly... it made the 
prose even more stiff and pedantic.

So I backed the change out. Not incorporated. If you feel strongly about 
this, let's discuss on the list.

> 
> The final graf in 2.2 should be bulleted like its predecessors.

Done.
> 
> In 2.2.x, there are numbered points like "X subtags MUST follow any
> ... subtags and MUST precede any ... subtags".  The numbers used are #2 in
> 2.2.3, #1 in 2.2.4, #2 in 2.2.5, #9 in 2.2.6, #3 in 2.2.7.  These should
> all be moved to #1 in each list, and minor wording variations removed.

Done. I used the form:

	Region subtags MUST follow any language or script subtags
	and MUST precede any other type of subtag.

(where the name of the subtag is changed along with the list of 
preceding subtags)

> 
> 2.2.4(3)(C) uses the phrase "with ambiguous ISO 3166 alpha-2 codes".
> This is not very clear to those who don't know the history, and should
> be expanded to something like "whose alpha-2 code was formerly (since
> <Date B>) associated with a different country".  Someone will have to
> look up what the cutoff date was -- I forget.

The is actually the Date C rule. That is, it covers UN M.49 codes for 
countries whose code has been reused by ISO 3166. At present, there are 
none of these.

So...

I reworked the graf to:

<t>UN numeric codes for countries or areas which are assigned ISO 3166 
alpha2 codes already present in the registry, MUST be defined according 
to the rules in <xref target="ianastability"/> and MUST be used to form 
language tags that represent the country or region for which they are 
defined. This happens when ISO 3166 reassigns a code formerly used for 
one country to another.</t>



> 
> 2.2.5:  s/suitable to form/suitable for forming/

1 occurrence replaced.
> 
> 2.2.8: s/current registered/currently registered/

ditto
> 
> 3.1.1: change the definition of folding to "Folding is always done on
> Unicode default grapheme boundaries".  That says what the current text
> says, and also prohibits folding in the middle of a Hangul syllable
> written as separate jamo.

:: shiver ::

Yes, I know. (laughing) I hoped to avoid implementing it in record-jar 
though. But you're right.

The sentence was rewritten as follows, to include the example:

Folding is always done on Unicode default grapheme boundaries (that is, 
never in the middle of a multibyte UTF-8 sequence nor in the middle of a 
combining character sequence).

> 
> 3.1.2:  In the explanation of "Preferred-Value", the first two bullet
> points say "Preferred-Value contains" but the third does not.

Done.

> 
> 3.1.3:  "The 'Subtag' field MUST use lowercase letters" says too much;
> it implicitly forbids digits.  What is meant is "The 'Subtag' field
> MUST NOT use uppercase letters".  Adding "all" before "uppercase" in
> the sentence about region subtags will clarify it.

Done.

> 
> 3.1.4: s/For records taken/For subtags taken/.

Done.
> 
> 3.1.4:  s/English localized names/localized English names/.

Done.

> 
> 3.1.7:  s/a prefix a prefix/a prefix/.

Done.
> 
> 3.1.4: it's not about countries changing their official names, as official
> names aren't even in the registry.  (Hands up all those who can say the
> official name of the U.S.  without looking it up.)  Remove "official".

Done.

> 
> 3.4(16): s/should it be possible/should it become possible/.
> 

Done.



-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.



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