Subject: [Ltru] extlang & deprecation (was draft updated

From: Peter Constable <[email-masked]>
Date: Tue, 1 Jul 2008 08:33:31 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Duerst
> Sent: Friday, June 20, 2008 12:01 AM
> Subject: Re: [Ltru] draft updated

> >Just letting you and the WG know that I continue to *strongly* favor
> >making "zh-cmn" and "zh-yue" (and the rest) the preferred forms, and
> >"cmn" and "yue" the pre-deprecated ones.
>
> [technical hat on] Seconded.       Regards,   Martin.

I haven't commented on this yet, nor has there been much discussion. I'm guessing that there are some differences of opinion here. Indeed, it strikes me that opinions may correlate to a large degree with opinions on whether to keep use of extlang or not.

I think we have three approaches that can be taken wrt extlang, only two of which have really been seen so far: for language productions X-Y and Y where X denotes a macrolanguage that encompasses Y

1. only allow one of X-Y or Y to be used
2. allow either X-Y or Y, but deprecate one of them
3. allow either X-Y or Y without deprecation

#1, of course, we have spent months on without reaching any consensus. Hence, I think #1 is dead.

#2 is currently on the table, but I see indicators that we could get stuck on it. (In fact, I'm guessing that one reason there haven't been responses on John's and Martin's comments is that people are afraid of getting into the same rut we were in wrt #1.)

I also see another potential concern wrt #2: I think there is an implicit assumption that X-Y and Y be considered semantically equivalent in terms of what they denote (although they may have slightly different behaviours in certain matching scenarios). Yet, with one or the other deprecated, there's some likelihood that some implementations will assume that the deprecated form can be largely disregarded in designing matching behaviour.

Btw, it should be noted that both #1 and #2 lead to consideration of cherry picking.

Now, let me propose an elaboration of #3 for adoption. This elaboration is captured by three points:

(a) that both X-Y and Y are freely allowed,
(b) that at the level of the language production X-Y and Y must always be considered a match (regardless of which is part of a tag or of a language range), but
(c) that how X and Y compare in matching is a separate consideration (perhaps with some suggestions but ultimately left to implementations).

This proposal frees us entirely from having to decide whether "zh-cmn"/"zh-yue" or "cmn"/"yue" is better. It would also mean there's no particular reason to cherry pick: the IETF-Language can discuss when it may or may not be beneficial to use the extlang formulation, but users can ultimately decide for themselves and (because of requirement b) they are assured of some degree of interoperability no matter which they choose.

Of course, this would probably need some revision to RFC4647, but I think we have been heading toward that regardless.

Thoughts?

Peter
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 1 Jul 2008 09:47:41 -0700

Peter wrote:
>
> I also see another potential concern wrt #2: I think there is an
> implicit assumption that X-Y and Y be considered semantically
> equivalent in terms of what they denote (although they may have
> slightly different behaviours in certain matching scenarios). Yet,
> with one or the other deprecated, there's some likelihood that some
> implementations will assume that the deprecated form can be largely
> disregarded in designing matching behaviour.

Disregarded may not be the right word. In my implementation, I canonicalize the deprecated form away before matching. A "well-formed" 4646 or 3066 implementation might not do that and arrive at different results. Besides, what you're proposing below is that both forms be treated as semantically equivalent, which is tantamount to "disregarding" one of the forms.

> Btw, it should be noted that both #1 and #2 lead to consideration

I don't see why.

What we're doing here is recommending one form over another for equivalent tags. Let me draw a parallel here. I work with a group of developers who code in Java. Like most development teams, we have coding style guidelines. One of them has to do with "if" statements. Both of the following forms (a) and (b) are completely equivalent, but one of them is preferred:

a) if (boolean) {
      // code
   } else {
      // code
   }

b) if (boolean)
   {
      // code
   }
   else
   {
      // code
   }

It doesn't matter which one we choose and our choice doesn't affect what you might choose. That's because the compiler reduces both to the same thing. However, here our parallel breaks down: X-Y and Y produce different results in non-validating implementations, so choosing one over the other is a Good Thing. And it isn't cherry picking if we ALWAYS do it the same way.

> (a) that both X-Y and Y are freely allowed,

Both #2 and #3 provide this.

> (b) that at the level of the language production X-Y and Y must
> always be considered a match (regardless of which is part of a tag
> or of a language range), but

This is where #3 is a non-starter for me: it requires us to change all of the matching schemes in ways that are incompatible with our previous tenets. In my implementation (which is validating), I didn't have to change the matching code because I canonicalize tags and ranges before matching. With a deprecation, the registry provides all of the information for this using the same mechanism I already use for mapping. See section 4.1.2 in the current draft, which says, in part:

--
As with other grandfathered tags, since implementations might not be able to associate the grandfathered tags with the encompassed language subtag equivalents that are recommended by this document, implementations are encouraged to canonicalize tags for comparison purposes.
--

I would tend to extend this recommendation to be more general.

In lookup, the main problem with #3 is that we are not given a specific canonical form to use for our fallbacks. If we don't choose a specific canonical form, people will have to implement additional code and keep track of other fields (macrolanguage, prefix) from the registry to equate X-Y and Y for fallbacks. Currently "Preferred-Value" is the only field you have to look at for canonicalization purposes and you look at the same field for *all* subtags and tags. And this code can be executed once separately from the lookup process, since it is a canonicalization step.

I'm more concerned about filtering, though. In filtering, for example, this would require a range like "zh-yue" to match a tag such as "yue-HK". This requires additional processing that none of the existing implementations or specifications have required. One of the delights of RFC 4646 was that existing tag matching schemes weren't broken.

>
> This proposal frees us entirely from having to decide whether "zh-
> cmn"/"zh-yue" or "cmn"/"yue" is better.

"Better" may not be the right word. "Preferred" would better describe the situation. Either form may be better for *your* application (or mine), depending on circumstances. What the deprecation says, in this case, is that implementations are free to/encouraged to eliminate the differences in a certain way when processing tags.

I like form Y over form X-Y for two main reasons:

1. It simplifies the tags.
2. It can be done without looking at the registry.

If one has a well-formed implementation, one can still canonicalize the extlang form using a regular expression (one does need the 4646bis ABNF to do this). But you can't add the macrolanguage without a glance at the registry.

> It would also mean there's
> no particular reason to cherry pick: the IETF-Language can discuss
> when it may or may not be beneficial to use the extlang formulation,
> but users can ultimately decide for themselves and (because of
> requirement b) they are assured of some degree of interoperability
> no matter which they choose.

Uh....... ietf-languages can discuss the benefits of extlang or no extlang for a given new registration with a macrolanguage, and then register subtags to match. But users only have a choice when ietf-languages gifts us with subtags of both types.

>
> Of course, this would probably need some revision to RFC4647, but I
> think we have been heading toward that regardless.

We may need to revise 4647 anyway, but we don't break as many things if we deprecate one form, especially if that form is the 'X-Y' form.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

---

From: John Cowan <[email-masked]>
Date: Tue, 1 Jul 2008 13:48:45 -0400

Peter Constable scripsit:

> (b) that at the level of the language production X-Y and Y must always
> be considered a match (regardless of which is part of a tag or of a
> language range), but

I don't understand what (b) means, particularly in contrast with (c).
The whole point in allowing both is that in some contexts X-Y works
better with naive matching, and in some contexts Y works better.

> (c) that how X and Y compare in matching is a separate consideration
> (perhaps with some suggestions but ultimately left to implementations).

I assume that this proposal is still in the context of only allowing a
small number of macrolanguages (plus 'sgn') as Xs in X-Y?

-- 
[W]hen I wrote it I was more than a little              John Cowan
febrile with foodpoisoning from an antique carrot       [email-masked]
that I foolishly ate out of an illjudged faith          http://ccil.org/~cowan
in the benignancy of vegetables.  --And Rosta
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Shawn Steele <[email-masked]>
Date: Tue, 1 Jul 2008 11:18:42 -0700

> This is where #3 is a non-starter for me: it requires us to
> change all of the matching schemes in ways that are
> incompatible with our previous tenets.

We already have to.  There's no way you can compare cmn with zh-HK or vice versa (if you want to) without modifying the doc.

> I didn't have to change the matching code because I
> canonicalize tags and ranges before matching. With a deprecation,
> the registry provides all of the information for this using
> the same mechanism I already use for mapping

The registry could provide similar equivalence for you, without deprecation, since you find the registry useful.

> "Better" may not be the right word. "Preferred" would better
> describe the situation. Either form may be better for *your*
> application (or mine), depending on circumstances.

That's not the definition of Deprecate:

  From OED & Webster online:

  Deprecate dep-re-cate:

  1. trans. To pray against (evil); to pray for deliverance from; to seek to avert by prayer. arch.
  3. trans. To plead earnestly against; to express an earnest wish against (a proceeding); to express earnest disapproval of (a course, plan, purpose, etc.).

  And:

  1 a: archaic : to pray against (as an evil) b: to seek to avert <deprecate the wrath...of the Roman people - Tobias Smollett>
  2: to express disapproval of
  3 a: play down : make little of <speaks five languages...but deprecates this facility - Time> b: belittle, disparage <the most reluctantly admired and least easily deprecated of...novelists - New Yorker>

So I have a hard time reading "deprecated" as being "allowed" to use either form, it seems that people would "pray" that I wouldn't use the deprecated form and "belittle" the implementation if a deprecated form was used :)

- Shawn

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 1 Jul 2008 11:44:45 -0700

> We already have to.  There's no way you can compare cmn with zh-HK
> or vice versa (if you want to) without modifying the doc.

(laughing) Sure you can: they don't match. Not even if you canonicalize in the other direction (to zh-cmn).

You can create, of course, a proprietary matching scheme that recognizes that there is some relationship between these two tags/ranges. But this is somewhat similar to Mark's famous handling of Breton and French. That is, "en-US" and "en-boont" don't match, even though, obviously, there is some kind of relationship between them.

> The registry could provide similar equivalence for you, without
> deprecation, since you find the registry useful.

Ah... but I already have a validating implementation that produces the "right" result via tag canonicalization (something I'm permitted to do to a tag or range). The distinction is that we'd be introducing a *separate* process only done in tag matching? Ick.

I find the registry useful for validation, but don't ignore the fact that I don't need the registry to peel off the macrolanguage from an extlang in a well-formed implementation. Requiring the registry for matching is a deep fundamental change to matching: one that I feel requires separate algorithm(s), not modifications to the existing ones.

>
> So I have a hard time reading "deprecated" as being "allowed" to
> use either form, it seems that people would "pray" that I wouldn't
> use the deprecated form and "belittle" the implementation if a
> deprecated form was used :)
>

Deprecated is not forbidden. It will never go away, but it might not produce the results that you want in *all* situations (cf. matching using 3066 implementations).

Addison

Addison Phillips

---

From: Peter Constable <[email-masked]>
Date: Tue, 1 Jul 2008 11:53:00 -0700

> From: John Cowan [mailto:[email-masked]]

> always

For X-Y-Z (Z being some string) and Y-Z, then X-Y-Z and Y-Z is always a match, but (c) whether X-Z and Y-Z are matched is a separate matter.

> small number of macrolanguages (plus 'sgn') as Xs in X-Y?

That choice is left open. Part of what I was saying is that I think there's less potential need to consider cherry picking in that particular regard for #3 than there is for #1 or #2: since X-Y and Y equivalence would be guaranteed, then there really isn't a need to say up front that only a small set of macrolanguages are candidates for X.

Peter

---

From: John Cowan <[email-masked]>
Date: Tue, 1 Jul 2008 14:57:55 -0400

> That's not the definition of Deprecate:

Dictionary definitions of "deprecate" aren't relevant, because it is a term
of art among programmers and standardizers.  From Wikipedia:

        In computer software standards and documentation, the term
        deprecation is applied to software features that are superseded
        and should be avoided. Although deprecated features remain
        in the current version, their use may raise warning messages
        recommending alternate practices, and deprecation may indicate
        that the feature will be removed in the future. Features are
        deprecated -- rather than being removed -- in order to provide
        backward compatibility and give programmers using the feature
        time to bring their code into compliance with the new standard.
                http://en.wikipedia.org/wiki/Deprecation

In our case, however, deprecated tags and subtags remain available for
use indefinitely: we never remove anything.  The same is true for
Linnaean species names:

        An example in paleontology would be Brontosaurus, a deprecated
        term for the genus Apatosaurus.

-- 
John Cowan    http://ccil.org/~cowan    [email-masked]
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 1 Jul 2008 12:03:20 -0700

>
> For X-Y-Z (Z being some string) and Y-Z, then X-Y-Z and Y-Z is
> always a match, but (c) whether X-Z and Y-Z are matched is a
> separate matter.

X-Z and Y-Z would match in *extended* filtering if X-Z is the range and Y-Z is equivalent to X-Y-Z, but at no other time.

It is useful to note that in lookup, you cannot obtain the Y-Z resource itself by requesting X-Z. You can obtain its parent resource X if you canonicalize to X-Y-Z and then fall back, but not Y-Z (or even X-Y-Z).

In basic filtering you can never obtain Y-Z by requesting X-Z. Neither can you obtain X-Z by requesting Y-Z (or X-Y-Z). As a reminder of why: consider Suppress-Script.

> That choice is left open. Part of what I was saying is that I think
> there's less potential need to consider cherry picking in that
> particular regard for #3 than there is for #1 or #2: since X-Y and
> Y equivalence would be guaranteed, then there really isn't a need
> to say up front that only a small set of macrolanguages are
> candidates for X.
>

Multiple tag choices for the same meaning are Bad News, regardless of what form they take. We should create a few as possible (but no fewer). The "equivalence guarantee" you seek is, I fear, fraught with implementation headaches, since it requires interior knowledge of the subtag registry in order to work.

Addison

---

From: Shawn Steele <[email-masked]>
Date: Tue, 1 Jul 2008 12:20:26 -0700

It's the "and should be avoided" part that trips me up.

- Shawn

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 1 Jul 2008 12:24:34 -0700

Use RFC 2119 meaning of "SHOULD" here:

   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

If you think you want to use the deprecated form, think about the implications (sometimes you won't get the matching you desire) before proceeding. Since we make clear what those considerations are, people can make an informed decision.

Of course, we still have a disagreement (so far between Mark/Addison and Martin/John) about which way to point the deprecating arrow, but that's a small matter.

Addison

Addison Phillips

> From: Shawn Steele [mailto:[email-masked]]
> Sent: Tuesday, July 01, 2008 12:20 PM
> To: John Cowan
> Subject: RE: [Ltru] extlang & deprecation (was draft updated
>

---

From: Peter Constable <[email-masked]>
Date: Tue, 1 Jul 2008 12:32:09 -0700

> From: Phillips, Addison [mailto:[email-masked]]

> > I also see another potential concern wrt #2: ...
> Disregarded may not be the right word...

No, that's what I meant: you may use canonicalization to ensure that the deprecated form is always considered, but nothing requires that.

> > Btw, it should be noted that both #1 and #2 lead to consideration

Well, for #2, we have started to consider cherry picking (at least, I've had that impression), and the reasons for considering it applied just the same to #1 -- we just didn't get to a point while #1 was on the table of actually considering it. But this isn't a point worth debating.

> It doesn't matter which one we choose and our choice doesn't affect
> what you might choose. That's because the compiler reduces both to the
> same thing. However, here our parallel breaks down: X-Y and Y produce
> different results in non-validating implementations, so choosing one
> over the other is a Good Thing. And it isn't cherry picking if we
> ALWAYS do it the same way.

Again, I thought that we were cherry picking in which cases the extlang form was even considered valid (IOW, cherry picking the macrolanguages): zh, ar, sgn and a few others.

> Both #2 and #3 provide this.

I mean in the sense that neither is identified as preferred.

> This is where #3 is a non-starter for me: it requires us to change all
> of the matching schemes

True.

> in ways that are incompatible with our previous
> tenets.

Haven't groked that yet. (I just thought of all this and wrote it up immediately for feedback.)

> In lookup, the main problem with #3 is that we are not given a specific
> canonical form to use for our fallbacks. If we don't choose a specific
> canonical form, people will have to implement additional code and keep
> track of other fields (macrolanguage, prefix) from the registry to
> equate X-Y and Y for fallbacks. Currently "Preferred-Value" is the only
> field you have to look at for canonicalization purposes and you look at
> the same field for *all* subtags and tags. And this code can be
> executed once separately from the lookup process, since it is a
> canonicalization step.

A possible concern is that "Preferred-Value" is not only used in canonicalization *for matching purposes*, but it is also what people SHOULD be using to tag all their content and interchange: as the opening sentence of 4.5 says,

-------------
Since a particular language tag is sometimes used by many processes, language tags SHOULD always be created or generated in a canonical form.
-------------

So, indeed, the means we have for supporting canonicalization in the registry is also how we handle deprecation, and so we currently have to deprecate either X-Y or Y to handle these in canonicalization. Just as you say. The concern is that we are also saying that only one or the other SHOULD be used in interchange and in tagging content. I'm concerned that might lead to the very same barrier to consensus that we had for #1: some think content/interchange should use (say) "cmn" while others would like to see "zh-cmn".

I guess what I'm really suggesting for #3 is that we still have the effects of canonicalization used in matching without saying that the canonical form (just wrt extlang -- X-Y vs. Y) is what SHOULD always be generated.

> "Better" may not be the right word. "Preferred" would better describe
> the situation.

OK.

> 2. It can be done without looking at the registry.

I agree.

> Uh....... ietf-languages can discuss the benefits of extlang or no
> extlang for a given new registration with a macrolanguage, and then
> register subtags to match. But users only have a choice when ietf-
> languages gifts us with subtags of both types.

I'm not making myself clear: whereas currently, we have (IIUC) cherry picked only certain macrolanguages and sgn as potential prefixes for extlang, I was suggesting for #3 that LTRU doesn't need to make those choices up front, that the RFC can specify *any* macrolanguage (or sgn) can be a prefix for extlang, and then it can be left to IETF-Languages to decide (perhaps differently for different cases) whether X-Y or Y is better in general (i.e. for most applications) / preferred for purposes of tagging and interchange. (We'd still want something that specifies a "canonical" form that would be picked up automatically in matching.)

Again, the main concern I'm trying to address anticipated difficulty in agreeing on whether content should get tagged "zh-cmn" or "cmn".

Peter

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 1 Jul 2008 13:12:32 -0700

Hi -

As a technical contributor...

> From: "Shawn Steele" <[email-masked]>
> To: "John Cowan" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
...

I have the same difficulty.  In the world of MIBs, RFC 2578 says:
   The value "current" means that the definition is current and valid.
   The value "obsolete" means the definition is obsolete and should not
   be implemented and/or can be removed if previously implemented.
   While the value "deprecated" also indicates an obsolete definition,
   it permits new/continued implementation in order to foster
   interoperability with older/existing implementations.

In that universe, "deprecated" has different implications for "agent"
and "manager" application developers, but translating that thinking
to the world of language tags, it would mean: "if something is deprecated,
you should be prepared to process it, but, to the extent it is practical, 
should avoid generating it."  The use of the term "deprecated" was
deliberate in MIB land, because we did indeed want to maintain the
"please don't do this" semantic.  Stuff there gets deprecated because
it has proven to be problematic or inadequate, but is too entrenched
to permit an outright declaration of "obsolete."

My reason for saying "SHOULD  be prepared to process it" is that
in my experience folks balk at putting tests for "deprecated" bits
into conformance test suites or acceptance criteria.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 1 Jul 2008 13:48:06 -0700

> Well, for #2, we have started to consider cherry picking (at least,
> I've had that impression), and the reasons for considering it
> applied just the same to #1 -- we just didn't get to a point while
> #1 was on the table of actually considering it. But this isn't a
> point worth debating.

Actually, we considered and rejected it for #1, IIRC. Then some attempts were made at a compromise that used cherry-picking. Given all that, I don't see why #3 doesn't potentially lead to cherry-picking too. The picking of cherries is orthogonal to the solution chosen.

>
> Again, I thought that we were cherry picking in which cases the
> extlang form was even considered valid (IOW, cherry picking the
> macrolanguages): zh, ar, sgn and a few others.

Well, yes. Unless we don't.

> up immediately for feedback.)

I had in mind, in particular, that our current matching schemes require only the tags/ranges themselves, without any a priori information, in order to function. Canonicalization (a separate process) helps and is recommended here (but not required) because strict subtag matching can't deal with tag/subtag replacement (deprecation). Not requiring the registry is, to my mind, a fundamental tenet of matching as it sits today.

>
> A possible concern is that "Preferred-Value" is not only used in
> canonicalization *for matching purposes*, but it is also what
> people SHOULD be using to tag all their content and interchange: as
> the opening sentence of 4.5 says,
>

I agree that this applies. But I think it is important that we establish a general trend in tag choice. Multiple choices in language tags are bad news.

>
> So, indeed, the means we have for supporting canonicalization in
> the registry is also how we handle deprecation, and so we currently
> have to deprecate either X-Y or Y to handle these in
> canonicalization. Just as you say. The concern is that we are also
> saying that only one or the other SHOULD be used in interchange and
> in tagging content. I'm concerned that might lead to the very same
> barrier to consensus that we had for #1: some think
> content/interchange should use (say) "cmn" while others would like
> to see "zh-cmn".

We do have a long-ish section about extlangs in the section on tag choice to address this concern. We do say to use the canonical form and it *is* preferred and there are good reasons for us to prefer one form or another. However, the reason this compromise has any chance is that it allows people to disagree and still interoperate.

>
> I guess what I'm really suggesting for #3 is that we still have the
> effects of canonicalization used in matching without saying that
> the canonical form (just wrt extlang -- X-Y vs. Y) is what SHOULD
> always be generated.

Again, we can spell out the reasons one might choose to ignore the SHOULD in the section on tag choice.

> I'm not making myself clear: whereas currently, we have (IIUC)
> cherry picked only certain macrolanguages and sgn as potential
> prefixes for extlang, I was suggesting for #3 that LTRU doesn't
> need to make those choices up front, that the RFC can specify *any*
> macrolanguage (or sgn) can be a prefix for extlang, and then it can
> be left to IETF-Languages to decide (perhaps differently for
> different cases) whether X-Y or Y is better in general (i.e. for
> most applications) / preferred for purposes of tagging and
> interchange. (We'd still want something that specifies a
> "canonical" form that would be picked up automatically in matching.)

No, you're perfectly clear. However, not making a choice is, de facto, making a choice... because Doug would need to choose in 4645bis. Or we make no extlangs out of the box and let ietf-languages wrangle over individual extlang registrations later. Or we put all enclosed languages in as extlangs (making it more difficult to justify future non-registration of an extlang). Cherry-picking was employed in the current #2 precisely because (I believe you pointed this out) the real issue/need/desire for extlang revolved around a cherry-picked set and had increasingly little to do with macrolanguages per se. But we could choose to do all macrolanguages again. I actually don't care that much about how Quechua is tagged.

>
> Again, the main concern I'm trying to address anticipated
> difficulty in agreeing on whether content should get tagged "zh-
> cmn" or "cmn".
>

If the solution were obvious, we'd have been done months ago. The current compromise is that both camps are "satisfied" (you can use both forms), but one form is less preferred going forward. Most important, we describe what results to expect and what issues arise from a user's tag choices.

I am supporting and have made technical arguments for one particular position, but am willing to go the other way if that's where consensus lies. In part that's because I'll be free to do "what I know to be the Right Thing", even if doing it breaks from consensus.

Addison

---

From: Peter Constable <[email-masked]>
Date: Tue, 1 Jul 2008 17:54:00 -0700

> use indefinitely: we never remove anything.

Yes; but it's also the case that we tell people (at least, in the current draft) that they SHOULD not ever generate deprecated tags. So, *can* be used, and can always be validated, but *shouldn't* be used to tag content.

Peter

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 1 Jul 2008 17:58:53 -0700

Where "shouldn't" means "shouldn't unless you have a good reason". For
example, wide swaths of IT continue to use "iw" because Java does, and Java
continues to use it because it would break wide swaths of IT if it changed.

Mark

On Tue, Jul 1, 2008 at 5:54 PM, Peter Constable <[email-masked]>
wrote:

> Yes; but it's also the case that we tell people (at least, in the current
> draft) that they SHOULD not ever generate deprecated tags. So, *can* be
> used, and can always be validated, but *shouldn't* be used to tag content.
>
>
>
> Peter

---

From: Peter Constable <[email-masked]>
Date: Tue, 1 Jul 2008 18:06:32 -0700

> I agree that this applies. But I think it is important that we
> establish a general trend in tag choice. Multiple choices in language
> tags are bad news.

OK, so you're saying we need to move the trend in tag choice either toward everyone tagging things as "zh-cmn"/"zh-yue"/etc., or toward everyone tagging things as "cmn"/"yue"/etc. We've got different opinions on which way this should go. Some here *strongly* favour the former; I've got some people telling me they *strongly* favour the latter. How will we reach a consensus?

The main intent of what I've proposed is to say that we don't push one over the other. (Kind of like Latin precomposed/decomposed representations in Unicode: the Standard doesn't try to push either over the other.)

> If the solution were obvious, we'd have been done months ago. The
> current compromise is that both camps are "satisfied" (you can use both
> forms), but one form is less preferred going forward. Most important,
> we describe what results to expect and what issues arise from a user's
> tag choices.

Well, are both camps "satisfied"? We're not just saying you can use both forms; we'd be saying, "You can use either, but we really want you to use this one."

Peter