Re: [Ltru] draft-davis-t-langtag-ext

[Mark Davis ☕ <[e-mail]>]

Thanks for the feedback!

Updated working drafts:

   - draft-davis-t-langtag-ext.html<http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.html>
   - draft-davis-t-langtag-ext.txt<http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.txt>
   - draft-davis-t-langtag-ext.xml<http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.xml>

Mark
*— Il meglio è l’inimico del bene —*


On Fri, Aug 26, 2011 at 06:41, Gordon P. Hemsley <[e-mail]>wrote:

> On Tue, Aug 23, 2011 at 2:32 PM, Mark Davis ☕ <[e-mail]> wrote:
> > Updated working drafts:
> >
> > draft-davis-t-langtag-ext.html
> > draft-davis-t-langtag-ext.txt
> > draft-davis-t-langtag-ext.xml
>
> Editorial nits:
>
> The second to last paragraph in section 2.1 contains a sentence that reads:
> "Extension subtags, once defined by LDML, are never retracted or
> change in meaning in a substantial way."
>
> I presume that the 'never' is supposed to scope over 'change', but it
> doesn't, as currently written.
>
> I suggest rephrasing that sentence to something like these:
> "Extension subtags, once defined by LDML, are never retracted or
> changed in meaning in a substantial way."
> "Extension subtags, once defined by LDML, are never retracted nor
> changed in meaning in a substantial way."
> "Extension subtags, once defined by LDML, are never retracted and do
> not change in meaning in a substantial way."
> "Extension subtags, once defined by LDML, are never retracted or
> substantially changed in meaning."
>

done


> "Extension subtags, once defined by LDML, are never retracted nor
> substantially changed in meaning."
>
> My preference would probably be one of the last two.
>
> Also, and maybe I missed it, but I thought it was agreed to change the
> registration description (section 2.4) to "Specifying Transformed
> Content" or one of many other suggested changes?
>

Whoops, missed that in the title. fixed.


>
> I would also recommend separating "but not limited to" from the other
> text using commas on either side... but maybe that's just a personal
> preference of mine.
>

That would be too many commas, but added : after "to"

BTW, This will also undergo review by the RFC editor, so it is probably not
worth focusing too much on the lower-level typographical issues, especially
those that are a matter of preference.


>
> Also, could you clarify to me the purpose of the last paragraph of
> section 2.5? If a request is made for 'ja-t-it-m0-xxx-v21a-2007' and
> the recipient has content corresponding to that exact request, why
> would it ever even consider serving 'ja-t-it-m0-xxx-v21a-2009'?
> Wouldn't it make more sense to use an example where the recipient of
> the request does not have an exact match and thus must actually choose
> what it considers to be the closest equivalent?
>

good point. fixed.


>
> Fourth paragraph of section 2.9:
> "The XML structure lists the keys, such as <key extension="t"
> name="m0" alias="collation" description="Transliteration extension
> mechanism">,with subelements for the types, such as <type
> name="ungegn" description="United Nations Group of Experts on
> Geographical Names"/>."
>
> There is a space missing after the second comma.
>

Fixed ",with"


>
> And in section 4, the citation of "Section 3.7. Extensions and the
> Extensions Registry of "Tags for Identifying Languages" in [BCP47]" is
> inconsistent with the format used by similar citations throughout the
> document. I would recommend changing 'in' to 'of' and eliminating the
>

done


> period after '3.7', possibly couching the description in commas
> instead.
>

done, but we'll see what the RFC editor does with this, since it is a copy
of a similar section that is now an RFC.


>
> Hope that helps.
>

Yes, thanks!

Note to others: also fixed Yoshito=>Umaoka in

[RFC6067]Davis, M., Ed., Phillips, A., Ed., and Y. Yoshito, Ed., “BCP 47
Extension U,” September 2010.


>
> Gordon
>
> --
> Gordon P. Hemsley
> [e-mail]
> http://gphemsley.org/ • http://gphemsley.org/blog/
>