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

Re: [Ltru] Canonical variants



Remember, this is advice in the 'tag wisely' section, not in
canonicalization. Canonicalization is a dead end, because there is no
agreement on how to do it. It sounds like what you want is something like
the following:

- put prefix variant subtags before their suffixes (that is, if V1 occurs in
a Prefix of V2, V1 should go first)
- otherwise, where possible, keep prefixes and suffixes together
- otherwise, put "more significant" variant subtags before others
- otherwise -- or in case there is any doubt as to relative significance --
put variant subtags in random order, up to your whim of the moment ;-)

Personally, for the last phrase in clause 4, I'd advise people to use
alphabetical if one of the first three conditions don't apply, because at
least then we have some concrete advice for a determinate order. If you
leave clause 4 off, then random is what you are asking for...

Mark

On Thu, Jul 17, 2008 at 4:20 PM, Phillips, Addison <addison at amazon.com>
wrote:

>
>
> In my view, your text is now going in simply the wrong direction. I had
> proposed the following, which John seconded and you and Peter ignored.
>
> I didn't ignore it: I believe I disagreed with it, or at least aspects of
> it.
>
> However, what you and others seem to be implicitly assuming is the ordering
> "most significant subtag first". So just to get out of this issue, we could
> use that as a guiding principle. That is, we give the advice to users (in
> the "tag wisely section") for variant subtag ordering as follows:
>
> I agree that "most significant first" is the idea—for cases where the order
> is known. What my proposed text does is have tags that are related to
> one-another appear together. The Slovenian subtags are a good example here.
> This is on the theory, perhaps half-baked, that 'mumble' dialect of 'xx'
> language is being modified by general purpose variants, rather than the
> other way around.
>
> - put prefix variant subtags before their suffixes (that is, if V1 occurs
> in a Prefix of V2, V1 should go first)
> - otherwise, put "more significant" variant subtags before others
> - otherwise -- or in case there is any doubt as to relative significance --
> put variant subtags in alphabetical order.
>
>
>
> I don't like the alphabetical order thing, since I don't much care for
> reordering subtags at all---it's a lot of work to code and test it, for no
> practical (and modest theoretical) benefit. This may reflect a difference in
> implementation choice :-). I've always assumed that the order was important
> and used Vector or some sort of List, rather than Set. In part that's
> because order **is** important up to the variant position.
>
>
> At this point, I think we are better reverting to the text of 9 days ago on
> this topic, and just leaving this issue open for the future. We can thej+
Remember, this is advice in the 'tag wisely' section, not in canonicalization. Canonicalization is a dead end, because there is no agreement on how to do it. It sounds like what you want is something like the following:

- put prefix variant subtags before their suffixes (that is, if V1 occurs in a Prefix of V2, V1 should go first)
- otherwise, where possible, keep prefixes and suffixes together
- otherwise, put "more significant" variant subtags before others
- otherwise -- or in case there is any doubt as to relative significance -- put variant subtags in random order, up to your whim of the moment ;-)

Personally, for the last phrase in clause 4, I'd advise people to use alphabetical if one of the first three conditions don't apply, because at least then we have some concrete advice for a determinate order. If you leave clause 4 off, then random is what you are asking for...

Mark

On Thu, Jul 17, 2008 at 4:20 PM, Phillips, Addison <addison at amazon.com> wrote:

 

In my view, your text is now going in simply the wrong direction. I had proposed the following, which John seconded and you and Peter ignored.

I didn't ignore it: I believe I disagreed with it, or at least aspects of it.

However, what you and others seem to be implicitly assuming is the ordering "most significant subtag first". So just to get out of this issue, we could use that as a guiding principle. That is, we give the advice to users (in the "tag wisely section") for variant subtag ordering as follows:

I agree that "most significant first" is the idea—for cases where the order is known. What my proposed text does is have tags that are related to one-another appear together. The Slovenian subtags are a good example here. This is on the theory, perhaps half-baked, that 'mumble' dialg dialect of 'xx' language is being modified by general purpose variants, rather than the other way around.

- put prefix variant subtags before their suffixes (that is, if V1 occurs in a Prefix of V2, V1 should go first)
- otherwise, put "more significant" variant subtags before others
- otherwise -- or in case there is any doubt as to relative significance -- put variant subtags in alphabetical order.

 

I don't like the alphabetical order thing, since I don't much care for reordering subtags at all---it's a lot of work to code and test it, for no practical (and modest theoretical) benefit. This may reflect a difference in implementation choice :-). I've always assumed that the order was important and used Vector or some sort of List, rather than Set. In part that's because order *is* important up to the variant position.


At this point, I think we are better reverting to the text of 9 days ago on this topic, and just leaving this issue open for the future. We can then get back to the main issue, of seeing whether we are sufficiently done to do a real last call.

I tend to agree, although the text previously proposed on choice seems useful.

 

Addison

 


_______________________________________________
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.