Tag vs. Subtag, normative vs. informative

[Addison Phillips [wM]]

(Another personal response)

I think there are several issues tangled up here that should be broken out.
Whole tag vs. subtag is a question about the structure of the registry. A
separate issue is how the variant subtags may be used. Our draft makes the
usage information for variant subtags informative. I think all of Harald's
objections could be dealt with by making this information normative.

The structure of the registry is actually a practicality issue. Currently
the registered values are supposed to be atomic. They can't be used
generatively and you're not supposed to "look inside" them. This is at odds
with reality and leads to "gaps" in registration, as outlined by Doug Ewell.

Consider:

whole tag: de-1996

vs.

subtag: -1996
use with: de-*

In the first case, 8 registrations were made to deal with German
orthographic reform combined with the three countries most commonly
associated with German. However there exist sizeable German speaking
minorities in other countries (Russia, Argentina, Namibia, the USA, to name
a few) where content can NOT be labeled with other than the basic de-19xx
label because those countries were not registered. By contrast, the subtag
registry makes much more sense here, since the German orthographic variation
really applies specifically to German and not to a specific region. Once we
introduce script codes into the RFC, then the number of registrations
required to get full coverage becomes much larger, with no appreciable
utility in forcing all these extra registrations.

In other words, switching to subtag registration is a way of addressing the
obvious increase in work for the language (sub)tag reviewer inherent in
adding levels to the generative mechanism (specifically, script tags). It
keeps things manageable.

If a subtag really does apply to a specific country or region or
language+script, or whatever, this can be indicated in the registration
(indeed, it is REQUIRED information in any event). The registration of tags
or subtags changes not one whit except that we are spared stalking horse
registrations in which the registrant comes back repeatedly with a few more
variations to register, each building on the last. Cf. the discussion of
sl-rozaj recently. This doesn't lead to (for example) es-americas slipping
in: the bar for registration remains much the same.

So I think we should debate whether usages are normative and separately
whether subtags make more sense or not. I think that clearly, given the
other alterations in the draft, subtags make more sense. We should figure
out whether the information associated is normative or not (and I'm willing
to be persuaded on that score for the reasons cited by Harald).

Best Regards,

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Keld Jorn
> Simonsen
> Sent: lundi 29 decembre 2003 02:24
> To: Doug Ewell
> Cc: ietf-languages at alvestrand.no
> Subject: Re: RFC 3066bis: Philosophical objection (harsh)
>
>
> On Sun, Dec 28, 2003 at 10:26:56AM -0800, Doug Ewell wrote:
> > Harald Tveit Alvestrand <harald at alvestrand dot no> wrote:
> >
> > >> 4. "Silly subtag generation" should not be an issue. It has always
> > >> been possible to create 'silly' tags or at least tags with dubious
> > >> meaning with the generative mechanism. 'es-AQ', 'sv-CO', et cetera.
> > >
> > > Yes, and at times I think that the inclusion of the ISO 639 generative
> > > mechanism in RFC 1766 was a mistake, exactly for this reason.
> >
> > Having to register each language-country combination individually would
> > introduce significant overhead and delay.  Each previously unencoded
> > combination would have to be approved separately, and would be subject
> > to lengthy subsequent debate over whether it should have been encoded,
> > should be deprecated, etc.
>
> I don't think it is significant overhead. I am for registering
> each tag wholly as per Harald's arguments.
>
> Best seasons greetings
> keld
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages