Hi -
Subject line changed for tracking sanity....
As a technical contributor...
> From: "Edith Whitehead" <quaiouestenglish at yahoo.com>
> To: <ltru at ietf.org>
> Cc: <cewcathar at hotmail.com>; <mark at macchiato.com>; <addison at amazon.com>; <randy_presuhn at mindspring.com>
> Sent: Friday, February 06, 2009 9:31 AM
> Subject: Re: [Ltru] Editor's copy of draft-4646bis updated...
...
> ! 4.1 par 3
>
> { ORIGINAL TEXT }
>
> " Standards, protocols, and applications that reference this document
> normatively but apply different rules to the ones given in this
> section MUST specify how language tag selection varies from the
> guidelines given here."
>
> { ! CORRECTION: CHANGE: "different rules to the . . . " > "rules different than those . . . "
> you can say : "rules different than," "rules different from," or "different rules than,"
> but where do you get "different rules to"? It's not English.
Nor is "different rules than". If folks feel a need for a change,
"rules different from" would be more acceptible.
...
> ?? Also, CHANGE: "apply" to "adhere to" or simply "follow" (I like "adhere to" better;
> "apply" might be a word you use with applications and rules but I do not use it with anything but formatting,
> "formatting is applied . . ."
Disagree. I see no need for this change.
...
> ? Also, CHANGE: "the ones" to "those" (I think the the text is more cohesive with 'those'
> because it refers back to 'the rules'--this is an idea that Halliday has about cohesion too) }
Disagree. I see no need for this change.
> "Standards, protocols, and applications that reference this document
> normatively but adhere to rules different than those given in this section . . . "
This proposed usage of "than" is simply wrong, and I cannot support it.
...
> ! 4.1 par 6 item 1 second bullet
>
> {ORIGINAL TEXT }
> " Note that some subtag sequences might not represent the
> language a casual user might expect, especially if when
> relying on the subtag's description in the registry. "
>
> {! CORRECTION: delete either "if" or "when" as "if when" seems a bit redundant, right? }
Yup. However, the entire phrase "especially...registry" is not helpful
to the sense of the paragraph in question. Consequently, I think
that if a change is to be made, it would be better to delete
everything from the comma to the word "registry".
...
> ! 4.3 Par 1 Bullet 1 last sentence
>
> {ORIGINAL TEXT}
> "o A language priority list [RFC4647] describing a user's language
> preferences. This is a (possibly weighted) list of potentially-
> unrelated varieties, expressing a preference, rather than as a
> declaration about actual content."
...
> "This is a (possibly weighted) list of potentially unrelated varieties,
> expressing a preference, rather than a declaration of actual content."
Yup. However, this sentence is entirely redundant, so if there is going
to be a change, I'd rather just delete it.
> ! 5.1, par 4, sentence 2
>
> { ORIGINAL TEXT }
>
> " Inserted records can be placed anywhere in the appropriate section; there is
> no guarantee of the order of the records beyond grouping them together by 'Type'."
...
> "Inserted records can be placed anywhere in the appropriate section; there
> is no guarantee of their order beyond their being grouped together by 'Type'."
Ok. This "can" probably should be a MAY, but it's not a big deal and it's not
worth changing.
...
> ! 4.4.2 Par 1, last sentence
>
> { ORIGINAL TEXT }
>
> " Such truncation MUST NOT
> permit a subtag to be chopped off in the middle or the formation of
> invalid tags (for example, one ending with the "-" character)."
...
> "Such truncation MUST NOT permit the formation of invalid tags--
> either by chopping a subtag off in the middle, or by leaving a singleton without any subtag."
Disagree. The original text is gramamtically and technically correct.
The proposed text changes the meaning in a subtly incompatible way.
Consider the case where chopping a subtag in the middle does *not*
result in an invalid tag, but instead produces a tag containing a subtag
not present in the original.
....
> ? 3.5 "Registration Procedure for Subtags" Par 4, 2nd sentence
>
> { ORIGINAL TEXT }
>
> " Note that each response is not limited in
> size so that the request can adequately describe the registration."
>
> {COMMENTS: the word "response" is not clear here, and this sentence
> is awkward and unclear as a whole.
I think the sentence is abundantly clear in context, and see no need for change.
...
> ? 3.7 par 4 & 5
...
> {COMMENT: the two maintaining authorities, IANA, and the individual
> authority, might be confused by readers here??
...
Given the topic of the section, I find it difficult to imagine such confusion
taking place.
> "Failure on the part of the maintaining authority to maintain this record . . . "
It's difficult to keep a straight face when reading the proposed replacement.
...
> ? 4.1 Par 5
>
> { ORIGINAL TEXT }
>
> " A subtag SHOULD only be used when it adds useful distinguishing
> information to the tag. Extraneous subtags interfere with the
> meaning, understanding, and processing of language tags. In
> particular, users and implementations SHOULD follow the 'Prefix' and
> 'Suppress-Script' fields in the registry (defined in Section 3.1):
> these fields provide guidance on when specific additional subtags
> SHOULD be used or avoided in a language tag."
>
> {COMMENT/CORRECTION for Sentence 1:
> the way it's written, someone might interpret it as meaning that all subtags,
> including a primary language subtag, are optional, but a primary language
> subtag is really a good idea, a real SHOULD}
>
> INSERT AT BEGINNING--replace sentence 1 with 2 sentences
>
> "All language tags--except those that are exclusively private use--
> SHOULD include one (primary) language subtag. Any additional
> subtag SHOULD only be included when it adds useful distinguishing
> information to the tag. "
Strongly disagree. This changes the sense of the text.
[As co-chair: it took extensive discussion to reach agreement on
this text, and I'm extremely relectuant to even consider changes to
it unless something is demonstrably broken.]
> ?? {A SECOND COMMENT/CORRECTION for Sentence 3: word
> choice; change "follow" to "consult" I would never say "follow"
> for either unless I said "follow the guidelines . . ."; "consult"
> is the best word with "users" probably; not sure at all about
> implementations but I would not say "follow"}
Disagree. While I appreciate the preference for "consult", it
does not mean the same thing as "follow".
...
> ? 4.1 par 6 item 2 example second bullet last sentence
>
> { ORIGINAL TEXT }
>
> "(The tag "uz-Zxxx"
> could also be used where content is not written, as the subtag
> 'Zxxx' represents the "Code for unwritten documents".)"
>
> { COMMENT/CORRECTION I do not see what clarity or information
> the word 'code' adds to this sentence so I CORRECTED it }
I believe it's a quote from the subtag's registry enty.
> "The tag "uz-Zxxx"
> could also be used where content is not written as the script subtag 'Zxxx' is used to indicate unwritten documents"
I think this would be a step backwards, since it de-emphasizes the generative nature
of subtags.
...
> ? 4.1.1 par 5, last sentence
>
> ORIGINAL TEXT }
>
> "For example, Romanian ('ro') and
> Moldavian ('mo') do not share a macrolanguage, but are far more
> closely related to each other than Cantonese ('yue') and Wu ('wuu') ,
> which do share a macrolanguage."
> {! COMMENT: the [ro] [mo] example is a bit of a problem as one of the
> subtags has now been deprecated; [ca] and [oc], 'Catalan' and
> 'Occitan'/'Provencal,' would be better examples;
> alternately you might choose [gsw] 'Alsatian' or 'Schwyzerdütsch'
> and [swg] 'Swabian'--but I know less about Alsatian;
> There may be other possibilities; on a quick perusal of RFC 4645
> I did not find khmer, for example, though I discovered there are some
> maybe mutually intelligible varieties any & know little about Asian
> languages anyway}
Strongly disagree. The example serves its purpose as it is,
and none of the cases cited is as dramatic and clear-cut
as that of Romanian and Moldavian. (Which explains nicely
*why* the subtag met the fate that it did.)
[As co-chair: there already seems to be a rough consensus
to not change this section.]
> 4.2 par 5
> { ORIGINAL TEXT }
> " This relationship is not guaranteed in all cases: specifically,
> languages that begin with the same sequence of subtags are NOT
> guaranteed to be mutually intelligible, although they might be. For
> example, the tag "az" shares a prefix with both "az-Latn"
> (Azerbaijani written using the Latin script) and "az-Cyrl"
> (Azerbaijani written using the Cyrillic script). A person fluent in
> one script might not be able to read the other, even though the
> linguistic content (e.g., what would be heard if both texts were read
> aloud) might be identical. Content tagged as "az" most probably is
> written in just one script and thus might not be intelligible to a
> reader familiar with the other script."
> {COMMENT/CORRECTION I found the language, 'this relationship
> is not guaranteed,' kind of vague. Also I did not like the phrase, 'written
> in just one script'--an example specifying one of the two scripts might help
> make this sentence clearer to someone skimming this. I tried to rewrite
> this paragraph: I simplified the first sentence and used more specific
> language (the word 'always' here, does refer the reader back to what's
> been said in the paragraph above about the general relationship between
> language tags sharing a prefix--one that we now see does not always
> guarantee mutual intelligibility); I also rewrote slightly the second sentence,
> and inserted "however" (to tie back to the previous statement)
> "only" into the fourth sentence.}
>
> ?? "Tags that share the same prefix are not always mutually intelligible.
> For example, the prefix 'az' is shared by both "az-Latn" (Azerbaijani
> written using the Latin script) and "az-Cyrl" (Azerbaijani written using
> the Cyrillic script). A person fluent in one script might not be able to
> read the other, even though the
> linguistic content (e.g., what would be heard if both texts were read
> aloud) might be identical. However, content tagged as "az" most
> probably is written in just one of these scripts and thus might not
> be intelligible to a reader familiar with only the other script."
Disagree. The change to the first sentence makes it sound like
mutual intelligibility is normally presumed when there is a shared
prefix, and that cases like this are rare exceptions. The existing text
is clearer and more to the point.
> ? 4.5 par 2 item 4 & par 4 "Example . . . "
...
> { COMMENT/CORRECTION: the first example actually goes with item
> 5 & the second with item 4 so it's confusing; I prefer to have the examples
> with the items they illustrate; thus I'd move the second of the examples
> so that it followed item 4-- }
I'm neutral on this proposal. I see the benefits to interspersing the
examples with the list of rules, but I also see advantages to the
current organization with the examples following the rules.
I'm not persuaded at all that this is a change that in any way
*needs* to be made.
...
> ?? 3.5 par 21
...
> {! COMMENT/CLARIFICATION ? Please explain "SHALL NOT" versus "MUST NOT"--
This is spelled out in RFC 2119.
Randy
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.