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

I've read through this document and have no significant objections.

My earlier and oft-stated concerns about the data not being available
until the document is approved have been largely satisfied; I am
confident that the sample data in Section 2.9 will be representative of
the real data.

I'm looking forward to this extension structure becoming available for
use in language tags.

Editorial nits, neither of which should hold up approval:

1. In Section 2.5, item (a), "the mechanism subtag 'UNGEGN'" should be
changed to "the mechanism subtag 'ungegn'", using the same casing as the
tag which immediately follows.

2. In Section 2.9, paragraph 4, the XML structure example makes
reference to the "collation" key from the 'u' extension, which might be
confusing.--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell ­

Thanks! I fixed both of those.

Updated working drafts:

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


Mark
*— Il meglio è l’inimico del bene —*On Tue, Aug 23, 2011 at 10:17, Doug Ewell  wrote:

> I've read through this document and have no significant objections.
>
> My earlier and oft-stated concerns about the data not being available
> until the document is approved have been largely satisfied; I am
> confident that the sample data in Section 2.9 will be representative of
> the real data.
>
> I'm looking forward to this extension structure becoming available for
> use in language tags.
>
> Editorial nits, neither of which should hold up approval:
>
> 1. In Section 2.5, item (a), "the mechanism subtag 'UNGEGN'" should be
> changed to "the mechanism subtag 'ungegn'", using the same casing as the
> tag which immediately follows.
>
> 2. In Section 2.9, paragraph 4, the XML structure example makes
> reference to the "collation" key from the 'u' extension, which might be
> confusing.
>
> --
> Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
> www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell ­
>
>
> _______________________________________________
> Ltru mailing list
> 
> https://www.ietf.org/mailman/listinfo/ltru
>

As one of the instigators of language subtag proposals in the past for
transliteration schemes, I can say that the proposed extension looks
to cover all of the use cases I currently anticipate, and we're
looking into incorporating this extension into the BCP 47-based
language logic in the Zotero project and the citeproc-js
implementation of Citation Style Language.

Thanks to the authors for putting this together.

Avram Lyon

On Tue, Aug 23, 2011 at 2:32 PM, Mark Davis ☕  wrote:
> Updated working drafts:
>
> draft-davis-t-langtag-ext.html
> draft-davis-t-langtag-ext.txt
> draft-davis-t-langtag-ext.xmlEditorial 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."
"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?

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.

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?

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.

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
period after '3.7', possibly couching the description in commas
instead.

Hope that helps.

Gordon-- 
Gordon P. Hemsley

http://gphemsley.org/ • http://gphemsley.org/blog/

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.txt<http://unicode.org/repos/cldr/trunk/docs/rfc/...>
   - draft-davis-t-langtag-ext.xml<http://unicode.org/repos/cldr/trunk/docs/rfc/...>

Mark
*— Il meglio è l’inimico del bene —*On Fri, Aug 26, 2011 at 06:41, Gordon P. Hemsley wrote:

> On Tue, Aug 23, 2011 at 2:32 PM, Mark Davis ☕  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
> 
> http://gphemsley.org/ • http://gphemsley.org/blog/
>

Thanks for the feedback!

Updated working drafts:
draft-davis-t-langtag-ext.html
draft-davis-t-langtag-ext.txt
draft-davis-t-langtag-ext.xml
Mark
— Il meglio è l’inimico del bene —


One thing which we may need clarification...>Section 2.2 Structure
>
>d. The order of the subtags in a t extension is significant (seeSection 2.3 (Canonicalization) Canonicalization). 

I think this line does not match 2.3 Canonicalization - because the 
referenced section says - "with the fields ordered by the separators, 
alphabetically. "
I think we don't want to make the order of <field> significant - for 
example, assume there is a new <sep> "x0" is introduced - 

und-Cyrl-t-und-latn-m0-ungegn-2007-x0-foo

and

und-Cyrl-t-und-latn-x0-foo-m0-ungegn-2007

would be equivalent (but, the canonical representation is - 
"und-Cyrl-t-und-latn-m0-ungegn-2007-x0-foo" - because field "m0-*" and 
"field "x0-*" are sorted alphabetical order).

If my interpretation is correct, Section 2.2 d should be changed to "The 
order of the fields in a t extension is significant" (a field consists 
from <sep> and subtags represented by 3*8alphanum).



Otherwise, the latest edition looks clean and ready to go.

Yoshito Umaoka