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

Re: [Ltru] a modest proposal...



We can live with having extlang if limited to only zh and possibly ar or sgn, and as long as we include Shawn's proviso, that the non-extlang versions (eg "yue-Hant") be also valid. That is, one of the two equivalent forms can be deprecated with a preferred value of the other. 

Mark

On Mon, Jun 2, 2008 at 7:18 AM, Phillips, Addison <addison at amazon.com> wrote:
Martin wrote:

> >1. Restore a *single* extlang to the ABNF.
>
> This very, very much looks like a compromize. Of course, if we have
> at least one language with extlang, we need at least one subtag in
> the ABNF, so this is more a consequence of the proposals below than
> a proposal in itself.
>
> I personally understand the position of the XML Schema WG, and
> I also think that we should not change the wellformedness
> definition
> in RFC 4646, independent of how many (or how few, even zero)
> extlangs
> we use.

We don't have to change it, but it seems slightly silly to keep the extra extlangs around if we foreclose their use (writing code/tests for never-to-be-implemented features is considered bad practice).

> We have in this WG (though unofficially) produced test data
> that includes three extlangs to test implementations, and changing
> this doesn't seem to be a good idea to me (I can very quickly
> change
> my implementation, but I have no idea how many or how few
> downloaded/
> deployed there already are).

It would be okay with me to keep well-formedness the same. Having the three-extlang well-formedness check doesn't hurt very many people. However: a single extlang is much easier to code other operations for, such as validation or tag generation. The first repeating option comes at variant, at the end of the tag. Having written more than one implementation, I found multiple extlangs one of the more difficult things to implement well each time---and all for naught?

I guess the more compelling issue for me is that well-formedness checking ALREADY changes in 4646bis because we fixed the grandfathered production (which was much more permissive). In practice the bigger problem are 3066 well-formedness implementations, which we know are widespread.


>
> >3. Cherry pick *only* the 'zh' (and possibly the 'ar') encompassed
> >languages for registration as extlangs. This is done in the name
> of
> >compatibility alone.
>
> I'm personally okay with any kind of selection that would be able
> to make
> the "rough consensus" that we currently have a bit less rough. As I
> know
> there are some people who, for good reasons, don't like cherry-
> picking,
> such a selection, so having a good justification would help.

See Peter's email on this topic and see my justification just above: all this talk about macrolanguages has obscured the reason we're doing it, which is compatibility with existing tagging practice. Thus the Chinese, Sign Language, and possibly Arabic cherries make sense. Stuff like Malay and Konkani don't make the grade.


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



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