Mark Davis scripsit:
> > From what I can understand, which is by no means sure, the advocates
> > for B information want it so that they can vet tags like en-Latn(-GB)
>
> But for that, for the NC, they don't need the information that the default
> script is Latn. All they need to know is that if there are two scripts in
> the registry, then in that situation put no script in the tag.
I don't understand that sentence at all. To reiterate:
If I present the tag "en-Brai-YY" to a tag validator, it should reject the
tag as invalid, because region YY does not exist. If I present the tag
en-Latn, it should at least warn me that using Latn with en is undesirable.
If I present the tag en-Brai, it should accept it. This can only be done
if it's known that the default script for en is Latn.
You may not consider this use case worth supporting, but it *is* a use case.
> *Requiring* the default to be rejected is absolutely the wrong thing to do.
> Suppose that I am querying a database of phrase books for Thai. They contain
> a mixture of those using Latin and those using Thai script. I can issue 3
> queries:
>
> 1. th-Thai - give me only the ones in Thai, and written in the Thai script
> 2. th-Latn - give me only the ones in Thai, using a Latin transcription
> 3. th - give me anything.
Ah, but that's a constraint on language *ranges*, which are not semantically
the same as language *tags*. Language ranges are a concept belonging to
the matching draft, which may want to end up supporting things like "th-*"
or "th-*-*" that aren't tags at all.
We are talking here about a constraint on tags and only on tags.
> This is a perfectly sensible thing to do. But if #1 is illegal, it does not
> let users make a perfectly useful discrimination between #1 and #3.
What would be illegal on this view (not necessarily mine, I'm just trying to
be a mediator) is a document or other object being tagged th-Thai, not a
request for th-Thai.
> 1. I don't see that separating out D from C adds anything. But if you have a
> use-case, that would be interesting.
I was thinking that if you know there is no script, then you should reject
any attempt to add one except in "unusual script" mode. But perhaps that
is the same treatment that should be given to script-unknown languages.
--
Is not a patron, my Lord [Chesterfield], John Cowan
one who looks with unconcern on a man http://www.ccil.org/~cowan
struggling for life in the water, and when http://www.reutershealth.com
he has reached ground encumbers him with help? jcowan at reutershealth.com
--Samuel Johnson
_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.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.