Subject: [Ltru] editor's copy updated...

From: Addison Phillips <[email-masked]>
Date: Wed, 07 Mar 2007 12:37:51 -0800

I have updated the editor's copy of draft-03, including many (but not 
all) of Mark's proposed changes, plus various other modifications 
proposed over time.

Notable among these:

1. I included various items related to the (non-)use of script subtags 
with unwritten content. Section 4.1 in particular merits a look, since 
the edits were more than inserting a couple of sentences.

2. I changed the registry to UTF-8. I realize that Frank still doesn't 
love this change, but most all other respondents supported it.

3. Section 3.5 contains explicit instructions about what the LSR MUST do 
after each two-week period. My text is organized differently from Mark's 
proposal.

4. Section 2.2.9 (conformance) is heavily rewritten using Mark's 
proposal as a starting point. One notable innovation: I referenced RFC 
4647, something we couldn't do in RFC 4646.

Things I did not do (yet):

1. I didn't incorporate any changes to the LSR position or how it is 
filled, segmented, etc.

2. I haven't updated my xml2rfc files. I'll have to do that before 
submitting this draft.

ANBF checks. idnits are (otherwise) clean. A wdiff link is thoughtfully 
provided on my home page (Safari users are advised that you won't be 
able to read my home page :-( ).

   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-03.html
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-03.txt
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-03.xml

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

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

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 7 Mar 2007 16:38:04 -0800

Thanks for all your work.

1. I think there is enough of a consensus to include in 2.2.3

6 The script subtag Zxxx MAY be used to indicate unwritten content.

The text you have in 4.1 goes in the right direction, but does not let
someone explicitly indicate unwritten content.

2. The conformance stuff looks good.

3. In 3.1.2, you omitted:

A Prefix MUST not conflict with already registered subtag Prefixes. A
conflict would occur when when no valid tag could be constructed that would
contain the prefix, such as when when two subtags each have a Prefix that
contains the other subtag. For example, suppose that the subtag 'avariant'
has the prefix "es-bvariant". Then the subtag 'bvariant' cannot given the
prefix 'avariant', for that would require a tag of the form
"es-avariant-bvariant-avariant", which would not be valid.

Without that, there is nothing to prevent impossible prefix combinations.

4. I'm unhappy about the omissions of changes to the LSR term. Our goal
should be to have the best possible LSR. If that happens to be the current
holder, fine, but off the top of my head I can think of several much more
qualified candidates.

5. We need to have SOME statement on whether the ordering of variants is
important or not. My suggestion is that it should not be important. Since
the canonicalization is designed to remove irrelevant differences, it should
then contain the text.

Any sequence of variant tags MUST be reordered such that for each variant
subtags A and B, A comes before B if

   1. A has no prefix and B has a prefix
   2. or A and B are not ordered by #1, and A is part of a prefix (given
   the previous non-variant subtags) for B
   3. or A and B are not ordered by #1 or #2, and A is alphabetically
   before B

If it IS important, then we have to clearly state what the difference is,
and how people are to decide what the order is, and how the poor damn'd
software developer is to predict what that order is supposed to be.

Mark

-- 
Mark

---

From: Addison Phillips <[email-masked]>
Date: Wed, 07 Mar 2007 17:32:27 -0800

See below.

> 6 The script subtag Zxxx MAY be used to indicate unwritten content.

I agree and we should include an example in "choice".
> someone explicitly indicate unwritten content.

... which would be section 4.1. The text I put here was a (heavily 
edited) version of the text I discussed with Karen previously. How about 
adding this as an additional bullet following the "no audio" bullet:

--
Sometimes it is necessary to distinguish written from unwritten content 
in the same context. In particular, one is sometimes obliged to indicate 
the script for the written content: this can interfere with certain 
kinds of matching operation (such as Basic Filtering [RFC 4647]).  The 
script subtag 'Zxxx' is RECOMMENDED for indicating unwritten content in 
these cases. For example, when selecting resources in Serbian, one might 
tag text with "sr-Cyrl" and "sr-Latn", while unwritten content would be 
tagged with "sr-Zxxx".
--
> 2. The conformance stuff looks good.

Cool.

> conflict would occur when when no valid tag could be constructed that 
> would contain the prefix, such as when when two subtags each have a 
> Prefix that contains the other subtag. For example, suppose that the 
> subtag 'avariant' has the prefix "es-bvariant". Then the subtag 
> 'bvariant' cannot given the prefix 'avariant', for that would require a 
> tag of the form "es-avariant-bvariant-avariant", which would not be valid.

That's.... not true. I didn't think it belonged in 3.1.2. It belongs 
instead where I put it... in 3.1.7, where you'll find:

--
The field-body of the 'Prefix' field MUST NOT conflict with any 'Prefix' 
already registered for a given record. Such a conflict would occur when 
when no valid tag could be constructed that would contain the prefix, 
such as when when two subtags each have a 'Prefix' that contains the 
other subtag. For example, suppose that the subtag 'avariant' has the 
prefix "es-bvariant". Then the subtag 'bvariant' cannot given the prefix 
'avariant', for that would require a tag of the form 
"es-avariant-bvariant-avariant", which would not be valid.
--

My thinking here is that section 3.1.2 defines what the fields are and 
mean, but the field-specific sections are where we find the details 
about each one.

I should note that I was sorely tempted to edit this part of 3.1.7:

--
The field-body of the 'Prefix' field consists of a language tag whose 
subtags are appropriate to use with this subtag.
--

to say instead:

--
The field-body of the 'Prefix' field consists of an extended language 
range [RFC 4647] whose subtags are appropriate to use with this subtag.
--

> should be to have the best possible LSR. If that happens to be the 
> current holder, fine, but off the top of my head I can think of several 
> much more qualified candidates.

I omitted it because I wanted more time to work on incorporating the 
text. In particular, Michael suggested splitting the job (which is more 
work than your edits). I wanted to get this set of edits in place first. 
I do *not* disagree with the need to look at term, performance, and 
assignment rules.

However, I wanted to put all of the generally agreed or "near consensus" 
stuff in first to have a copy to fall back on.

> important or not. My suggestion is that it should not be important. 
> Since the canonicalization is designed to remove irrelevant differences, 
> it should then contain the text.

We disagree here: variant order is always important to matching, even 
though it isn't usually that important to tag meaning. Therefore users 
need to be aware of the subtag order. I'm on record as favoring 
exclusion of future "general purpose" variants to avoid the 
canonicalization problem, as well as several suggestions for how we 
might address the real problem, which is the recalcitrance of ISO 15924 
to register things you and I perceive to be "scripts" (in BCP 47 terms).

> 
> If it IS important, then we have to clearly state what the difference 
> is, and how people are to decide what the order is, and how the poor 
> damn'd software developer is to predict what that order is supposed to be.

The order is important. The order that the user puts them in is the 
order to use. General purpose variants are the source of the problem and 
their elimination would put paid to the issue (language-specific 
variants are either mutually exclusive or have Prefix relationships).

Thanks,

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 7 Mar 2007 17:47:16 -0800

comments below.

> I agree and we should include an example in "choice".

ok

> adding this as an additional bullet following the "no audio" bullet:

Looks good. Let's do it.

--
> instead where I put it... in 3.1.7, where you'll find:

Sorry, I missed that. Yes, that location and wording is fine.

I like that one, but we should float it by others before changing the text.

--
> stuff in first to have a copy to fall back on.

ok

> to register things you and I perceive to be "scripts" (in BCP 47 terms).

I agree with the latter.

I think the exclusion of general purpose variants doesn't solve the ordering
problem, but will reply separately.

> variants are either mutually exclusive or have Prefix relationships).

see other reply.

Thanks,

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Mar 2007 17:23:05 +0100

Addison Phillips wrote:

> these cases.

It's only an OPTION (a.k.a. MAY).

---
> "es-avariant-bvariant-avariant", which would not be valid.

That's IMO too verbose for a "you can't have prefix cycles" example.
Quick shot:

| The field-body of the 'Prefix' field MUST NOT conflict with any
'Prefix'
| already registered for a given record.  For example, suppose that the
| subtag 'avariant' has a prefix containing subtag 'bvariant', then the
| subtag 'bvariant' cannot have a prefix containing subtag 'avariant'.

If you're feeling naughty add a reference to "principia mathematica" :-)

---
> range [RFC 4647] whose subtags are appropriate to use with this subtag.

Let's not _force_ 4646bis readers to also read RFC 4647.  Those cycles
again...

---
> order to use. General purpose variants are the source of the problem
> and their elimination would put paid to the issue (language-specific

+1

Frank