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

From: "Doug Ewell" <[email-masked]>
Date: Tue, 23 Aug 2011 10:17:08 -0700

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

---

From: Mark Davis ☕ <[email-masked]>
Date: Tue, 23 Aug 2011 11:32:32 -0700

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.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 Tue, Aug 23, 2011 at 10:17, Doug Ewell <[email-masked]> wrote:

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

---

From: Avram Lyon <[email-masked]>
Date: Wed, 24 Aug 2011 02:04:20 +0400

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

---

From: "Gordon P. Hemsley" <[email-masked]>
Date: Fri, 26 Aug 2011 09:41:28 -0400

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

---

From: Mark Davis ☕ <[email-masked]>
Date: Fri, 26 Aug 2011 11:30:04 -0700

Thanks for the feedback!

Updated working drafts:

Mark

> substantially changed in meaning."

done

> Content" or one of many other suggested changes?

Whoops, missed that in the title. fixed.

> text using commas on either side... but maybe that's just a personal

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.

> what it considers to be the closest equivalent?

good point. fixed.

> There is a space missing after the second comma.

Fixed ",with"

> document. I would recommend changing 'in' to 'of' and eliminating the

done

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

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.

---

From: [email-masked]
Date: Tue, 30 Aug 2011 23:35:11 -0400

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 (see 
Section 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