Doug Ewell 2008-10-01 15.37:
Many wrote:
>
I am wholly and utterly opposed to allowing two records of the same type with the same subtag.And so am I.As am I.Me too. Could not live with this.
I think Mark actally expressed that registering "2003" as a subtag with the meaning "language reform linked to year 2003" would satisfy the uniqueness requirement.
Further down in this letter, you say that you disagree with him (and those of us who agree - at least I and Martin) in this.
Mark added:
>
I'm not opposed to de-1901 uz-1901 and so on. These are meaningful and easy for people to understand.As a matter of subtag assignment policy, which is really a question for ietf-languages,
Here I must agree that you take up a valid problem. Somehow the years would have to be reserved for a certain use. And what about e.g. "1996", would we be fiddling with what it was registereded as if we said that it from now on means "Language reforms of the following languages linked to year 1996: German, X, Y, Z"?
I think we are seriously overestimating both the need to tag variations identified by a year and the likelihood that users will connect these year numbers to the variations.
The question isn't, I think, "need to identify by year", but rather "need to identify language reform".
Regarding what's likely, that's a matter of what one are used to. The more there is a pattern, the more one will get used to.
German was a notable special case: it had a well-known, widely publicized, and much-debated orthographic revision for which we ended up creating the tag "de-1996" (with complement "de-1901" for the old orthography) back in the RFC 3066 whole-tag days. This was largely because we wanted to avoid something like "de-revised" knowing that it might be revised again some day. However, even now we talk of "de-1901" and "de-1996" as making distinctions that usually don't need to be made; see, for example, Section 4.1 of both RFC 4646 and draft-4646bis-17.
This socalled "well-known"-ness: All that is matter of how familiar you are with the particular language. I do not understand the likelyhood question. Language reforms is a common thing.
Since assigning "1994" to a Resian orthography invented by Han Steenwijk, which might well have been named for him instead, ietf-languages has been more and more willing to use year numbers to identify language variations, even those where the variation is not commonly associated with the year, or where regular revisions identifiable by year are not expected. We are about to register
'1959acad' for Belarusian even though we distinguish no other revisions of Academy Belarusian, and we were considering 'hpin1958' for Hanyu Pinyin even though the distinction we wanted to draw was between Hanyu and other Pinyins, not between 1958 and any other revision.
Here you bring up some relevant "hairs in the soup": Even if we establish that years are to mean "language reform", there will still be some subtags which do not fit nicely into the system, and also some subtags which aren't contstructed that way (as years) even though they (perhaps) could have been.
I'm not saying year numbers don't ever have their place, but it worries me when we expect them to be so common that we are thinking about compromising an important property of the Registry, uniqueness of subtag values within type, in anticipation that there will be tons of them.
So you disagree with Mark's intepretation of how to understand uniqueness.
Regarding "tons": The fact of the matter is that coming up with - and agreeing to - language subtag *names* is an extra burdon for any registerer. It is an extra fence to protect against registration of variation subtags. (The region subtags are not decided by us, you know, but by the UN ... etc.)
While OTOH, using year for language reforms, is very inviting. It could encourage registration. Should that be avoided?
And no, I don't consider this inconsistent with my position that 'coruc' and 'corur' and so forth are acceptable subtags. These may be cryptic, but they are not arbitrary.
-- leif halvard silli _______________________________________________ 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.