headers
Kent Karlsson | 6 Sep 20:19
Picon

RE: prefixes for date variants (was Re: Generic variants andArmenian dialects)

> Addison Phillips scripsit:
> 
> > I think the correct response to our problems here, as Mark 
> pointed out, 
> > is to REMOVE the validation requirement of checking the 
> variant prefix. 

I don't understand.

ANY new subtag will be "flagged" by a validating language tag processor
that has not been updated to include the new subtag. The same would
go for newly registered prefix(es) for already existing variant
subtag(s)
and a validating language tag processor that has not been updated
to include the new prefix(es).

If the "validation requirement of checking the variant prefix"
is removed, why not remove also the "validation requirement
of checking the subtag registration". (Which would make validation
rather pointless, since there would be no validation...)

I may have missed something, but did anyone (e.g. Mark) actually
suggest removing the prefix validation (for validating language
tag processors)?

	/kent k
Permalink | Reply |
headers
Peter Constable | 7 Sep 05:40
Picon
Favicon

RE: prefixes for date variants (was Re: Generic variantsandArmenian dialects)

> From: Kent Karlsson [mailto:kent.karlsson14 <at> comhem.se]

> > > I think the correct response to our problems here, as Mark
> > pointed out,
> > > is to REMOVE the validation requirement of checking the
> > variant prefix.
> 
> I don't understand.
> 
> ANY new subtag will be "flagged" by a validating language tag
processor
> that has not been updated to include the new subtag.

I was thinking the same thing.

Peter Constable
Permalink | Reply |
headers
Addison Phillips | 7 Sep 06:09
Picon
Favicon

Re: prefixes for date variants (was Re: Generic variantsandArmenian dialects)

Peter Constable wrote:
>> From: Kent Karlsson [mailto:kent.karlsson14 <at> comhem.se]
> 
> 
>>>> I think the correct response to our problems here, as Mark
>>> pointed out,
>>>> is to REMOVE the validation requirement of checking the
>>> variant prefix.
>> I don't understand.
>>
>> ANY new subtag will be "flagged" by a validating language tag
> processor
>> that has not been updated to include the new subtag.
> 
> I was thinking the same thing.
> 

For entirely unknown subtags, yes. But... with validation currently 
requiring prefix checking, adding a prefix causes existing parsers to 
reject known subtags.

Rejecting an unknown subtag is one thing. Rejecting an unknown prefix 
for a known subtag is something else. If we want to support generic 
variant subtags, the prefix is *informative* information about what that 
subtag means in a given context. So rejecting a subtag for using an 
unknown prefix is undesirable behavior, from a stability point of view.

The alternative is that the prefixes are normative and two validating 
parsers with different dates will produce different results. That is, 
the parser pre-new-prefix rejects tags validated by a parser
(Continue reading)

Permalink | Reply |
headers
Peter Constable | 7 Sep 18:27
Picon
Favicon

RE: prefixes for date variants (was Re: Generic variantsandArmenian dialects)

> From: Addison Phillips [mailto:addison <at> yahoo-inc.com]

> >> ANY new subtag will be "flagged" by a validating language tag
> > processor
> >> that has not been updated to include the new subtag.
> >
> > I was thinking the same thing.
> >
> 
> For entirely unknown subtags, yes. But... with validation currently
> requiring prefix checking, adding a prefix causes existing parsers to
> reject known subtags.

But it seems to me we're talking about *tag* validation, not *subtag*
validation, yet your response pertains to subtag validation. If that was
the issue, then all that matters is whether the subtag is known. But
because we're talking about tag validation, while the subtag may be
known the particular usage -- the entire tag -- is not. And rejection in
that case is no different than rejecting usage of a tag due to an
unknown subtag.

Peter Constable
Permalink | Reply |
headers
Addison Phillips | 7 Sep 18:57
Picon
Favicon

Re: prefixes for date variants (was Re: Generic variantsandArmenian dialects)

> 
> But it seems to me we're talking about *tag* validation, not *subtag*
> validation, yet your response pertains to subtag validation. If that was
> the issue, then all that matters is whether the subtag is known. But
> because we're talking about tag validation, while the subtag may be
> known the particular usage -- the entire tag -- is not. And rejection in
> that case is no different than rejecting usage of a tag due to an
> unknown subtag.
> 

If we were to create a true generic variant, the later registration of a 
prefix for that variant would potentially invalidate tags that had 
previously been valid. That's the hypothetical case we'd be fixing.

Addison

--

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.
Permalink | Reply |
headers
Peter Constable | 7 Sep 22:30
Picon
Favicon

RE: prefixes for date variants (was Re: Generic variantsandArmenian dialects)

> From: Addison Phillips [mailto:addison <at> yahoo-inc.com]

> If we were to create a true generic variant, the later registration of
a
> prefix for that variant would potentially invalidate tags that had
> previously been valid. That's the hypothetical case we'd be fixing.

Eh?

Suppose at T1 "western" is registered with one prefix, "hy". Thus at T1

	hy-western = good
	en-western = bad

Then at T2 > T1 "western" is updated to add a second prefix, "en". So

	post-T2 validator:
	hy-western = good
	en-western = good

	pre-T2 validator:
	hy-western = good
	en-western = bad

So?

Peter Constable
Permalink | Reply |
headers
Addison Phillips | 7 Sep 23:39
Picon
Favicon

Re: prefixes for date variants (was Re: Generic variantsandArmenian dialects)

Suppose at T1 "western" is registered with *NO" prefix (i.e. my "true 
generic"). At T1:

   en-western = good
   hy-western = good

At T2, add prefix "hy":

   en-western = bad   // argh!
   hy-western = good

This violates the idea that once a tag is valid, it is always valid.

QED.

Addison

--

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.
Permalink | Reply |
headers
Peter Constable | 8 Sep 00:15
Picon
Favicon

RE: prefixes for date variants (was Re: Generic variantsandArmenian dialects)

> From: Addison Phillips [mailto:addison <at> yahoo-inc.com]

> Suppose at T1 "western" is registered with *NO" prefix (i.e. my "true
> generic"). At T1:

Ah! Well, we long ago concluded that a true generic couldn't get it's
usage restricted, right? So once a *true* generic always a true generic.
But a true generic doesn't have any prefixes specified. (IIRC that was
the whole point of a thread discussed a couple of weeks ago.)

Peter Constable
Permalink | Reply |
headers
Frank Ellermann | 7 Sep 23:20
Picon
Picon

Re: prefixes for date variants

Peter Constable wrote:

>> If we were to create a true generic variant
                          ^^^^^^^^^^^^
> So?

No, your example was "pseudo-generic":  Addison (apparently)
discussed true generic variants:  Mark had explained here why
the 3066bis rules won't allow to downgrade "true generic" to
"pseudo-generic":

At T1 all what-Ever-generic were allowed.  And at T2 after T1
they must be still allowed (= at worst deprecated).  Mark
proposed that we make that clearer in 3066ter, because it's
not obvious.  Others proposed that we could just replace one
critical SHOULD by MUST to eliminate the possibility of any
"true generic" variants.  

Folks insisting on it can still create an extension registry
for their generic purposes.

Frank
Permalink | Reply |

Gmane