[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] Canonical variants



Works for me.

Mark

On Fri, Jul 18, 2008 at 11:22 AM, Phillips, Addison <addison at amazon.com> wrote:

Okay, here's what I did.

 

First, in "choice" I made changes to the text to recommend alphabetization following "most significant order" thus:

 

--

<t>Use variant subtags sparingly and in the correct order. Most variant subtags have a 'Prefix' field or fields that express the list of subtags that they are appropriate with. Variants SHOULD only be used with subtags that appear in one of these 'Prefix' fields. If a variant lists another variant in one of its 'Prefix' fields, it SHOULD appear directly after that variant in any language tag where both occur. General purpose variants (those with no 'Prefix' fields at all) SHOULD appear after any other variant subtags. Order any remaining variants by placing the most significant subtag first. If none of the subtags is more significant or no relationship can be determined, alphabetize the subtags. Because variants are very specialized, using many of them together generally makes the tag so narrow as to override the additional precision gained. Putting the subtags into another order interferes with interoperability, as well as the overall interpretation of the tag.

 

<list style="letters">

 

<t>For example, the tag "en-scottish-fonipa" (English, Scottish dialect, IPA phonetic transcription) is correctly ordered because 'scottish' has a 'Prefix' of "en", while 'fonipa' has no 'Prefix' field.</t>

 

<t>For example, the tag "sl-IT-rozaj-biske-1994" is correctly ordered: 'rozaj' lists "sl" as its sole 'Prefix'; 'biske' lists "sl-rozaj" as its sole Prefix. The subtag '1994' has several prefixes, including "sl-rozaj". However, it follows both 'rozaj' and 'biske' because one of its 'Prefix' fields is "sl-rozaj-biske".</t>

 

</list>

</t>

--

 

Then, in canonicalization I removed the text from the required canonicalizations. However, I think it makes sense to mention it there and permit it. So I included this text:

 

<t>If more than one variant appears within a tag, processors MAY reorder the variants to obtain better matching behavior or more consistent presentation. Reordering of the variants SHOULD  follow the recommendations for variant ordering in <xref target="choice"></xref>.</t>

 

 

Does that work for everyone?

 

Addison

 

Addison Phillips

Globalization Architect -- Lab126

 

Internationalization is not a feature.

It is an architecture.

 

From: mark.edward.davis at gmail.com [mailto:mark.edward.davis at gmail.com] On Behalf Of Mark Davis
Sent: Friday, July 18, 2008 8:34 AM
To: Martin Duerst
Cc: Phillips, Addison; ltru at ietf.org


Subject: Re: [Ltru] Canonical variants

 


Mark

On Thu, Jul 17, 2008 at 6:42 PM, Martin Duerst <duerst at it.aoyama.ac.jp> wrote:

At 08:51 08/07/18, Mark Davis wrote:
>There are two parts that I think you don't have yet in the choice; order by prefix relations (you have) then most significant tag first, then alphabetic.

[as a technical contributor]

If 'alphabetic' comes after most significant subtag first, I'm able
to tolerate it in a section on how to create tags.

 

good

 

When it comes to
any potential change of tags, I think the best advice we can give
is 'leave as is', and I very much do not want to see 'alphabetical'
in there, because the "most important" may be a judgement by the
creator, which should be respected.

 

I'm ok with leaving that out -- it sounds like we may have sufficient consensus to move forward on this, putting in the tag wisely.

 

(On the side, since I really don't want to stir this up again: my view is if I pass in a tag xx-variant1-variant2 and some collection of data has xx-variant2-variant1, as far as I'm concerned that should return as a perfect match: as likely as not, any difference in the ordering is purely arbitrary on the part of either the user making the first tag or the user making the second tag. And if they are a perfect match, that implies that the canonical forms should be the same. But there is clearly no consensus on that so the important thing is to close this and move on.)

 



Regards,   Martin.



>Then I'm happy. (Well, reasonably. There is that whole war in Iraq, and melting economy, and moron president thing...)

[chair hat on: let's concentrate on the work of this WG :-] 

 







#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp

 


_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.