Subject: RE: [Ltru] Re: Proposed Text for Moving Forward

From: "Addison Phillips" <[email-masked]>
Date: Thu, 14 Apr 2005 12:24:15 -0700

FWIW, I would prefer a design closer to what I originally proposed (with only one field type), but I documented what appears to be currently nearer consensus.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Addison Phillips
> Sent: jeudi 14 avril 2005 12:08
> To: John Cowan; Mark Davis
> Cc: [email-masked]
> Subject: RE: [Ltru] Re: Proposed Text for Moving Forward
> 
> Below is a proposed version of the section "Choice of Language Tag". In
> writing this text, I began a heavy reorganization of the document's
> sections. Too many forward references were being created, so I have
> followed our previous discussion and:
> 
> 1. Made the IANA Considerations section a very small separate section.
> 2. Made what was titled "IANA Considerations" into "Registry Format and
> Maintenance"
> 3. Made a new section "Formation and Processing of Language Tags"
> following the format and maintenance section. This contains "Choice",
> "Meaning", "Canonicalization", and "Considerations of Private Use"
> sections.
> 
> I have not yet revised the registry handling text to reflect the
> additional fields and so forth, so please don't look there. For this
> discussion I have focused on the "Choice of Language Tag" section.
> 
> The new versions are posted on:
> 
> http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html
> http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt
> 
> Here is the salient text from the "Choice" section:
> 
> ---
> Many applications can benefit from the use of script subtags in language
> tags, as long as the use is consistent for a given context. Script subtags
> were not formally defined in RFC 3066 and their use may impact matching
> and subtag identification by implementations of RFC 3066 and its
> predecessor RFC 1766, as these subtags appear between the primary language
> and region subtags. For example, if a user requests content in an
> implementation of Section 2.5 of RFC 3066 [22] using the language range
> "en-US", content labeled "en-Latn-US" will not match the request.
> Therefore it is important to know when script subtags will customarily be
> used and when they should not be used.
> 
> The language subtag registry defines two informational fields to guide
> users in the choice of whether to use script subtags for a specific
> application. These fields SHOULD be used as follows:
> 
>     If the primary language subtag has an Expected_Script_Subtag field,
> then the use of a script subtag is strongly RECOMMENDED for all
> applications. This field is used in records for primary language subtags
> that are customarily or frequently written in more than one script and
> which may be ambiguous without script information.
> 
>     If the primary language subtag has a Default_Script field, then that
> script subtag SHOULD NOT be used to form the language tag unless it
> conveys additional information necessary to the specific application. For
> example, the subtag 'Latn' should not be used with the primary language
> 'en' because most English documents are written in the Latin script and it
> adds no distinguishing information. However, if a document were written in
> English mixing Latin script with another script such as Braille ('Brai'),
> then the content author may choose to indicate both scripts to aid in
> content selection, such as the application of a stylesheet.
> 
>     If the primary language subtag has neither an Expected_Script_Subtag
> field nor a Default_Script field, then the script subtag SHOULD NOT be
> used to form the language tag unless it conveys additional information
> necessary to the specific application. Most languages that have neither
> field are either not customarily written or are written, but the script is
> not known in the registry. Speakers of these languages are encouraged to
> register the appropriate information in the registry.
> 
> Extended language subtags (type 'extlang' in the registry, see Section 3.1)
> also appear between the primary language and region subtags andare
> reserved for future standardization. Applications may benefit from their
> judicious use in forming language tags in the future and similar
> recommendations are expected to apply to their use as apply to script
> subtags.
> 
> ---
> 
> 
> Addison P. Phillips
> Globalization Architect, Quest Software
> Chair, W3C Internationalization Core Working Group
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of John Cowan
> > Sent: jeudi 14 avril 2005 11:34
> > To: Mark Davis
> > Cc: [email-masked]
> > Subject: Re: [Ltru] Re: Moving Forward
> >
> > Mark Davis scripsit:
> >
> > > A. We know the language is customarily used with more than one script
> > > B. We know the language is customarily used with one script
> > > C. The information for A or B is not available in the registry: either
> > just
> > > not entered yet, or hard to find out.
> >
> > You omit:
> >
> >   D. The language is not customarily used with any script.  (Any
> language
> > may
> >   be transcribed in writing, as any language may be spoken over the
> radio;
> >   but just the same, Chinese is written and Burushaski is not, as Navajo
> > is
> >   regularly broadcast and Akkadian is not.)  This does not apply to
> > current
> >   639-2 languages but will apply to 639-3 languages.
> >
> > > As I said before, I have not yet seen an implementation scenario where
> > we
> > > need the infomation in B, and both the strategies that use it require
> > > entering in much more data than the ZZ scenario. So I'd like to see a
> > > scenario that drives B clearly stated.
> >
> > >From what I can understand, which is by no means sure, the advocates
> > for B information want it so that they can vet tags like en-Latn(-GB)
> > and warn against or reject them.  Without B information we cannot
> > distinguish between en-Brai (anomalous, so correct) and en-Latn
> > (undesirable).
> >
> > > 2. As Peter says, we mustn't say MUST NOT, however: there are
> scenarios
> > in
> > > which it may be appropriate to use en-Latn or ko-Latn.
> >
> > I believe the desire of this part of the WG is to reject en-Latn
> > absolutely (because it is the default) while still retaining the
> > possibility of ko-Latn.
> >
> > --
> > All Gaul is divided into three parts: the part          John Cowan
> > that cooks with lard and goose fat, the part
> > www.ccil.org/~cowan
> > that cooks with olive oil, and the part that
> > www.reutershealth.com
> > cooks with butter. -- David Chessler
> > [email-masked]
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: Misha Wolf <[email-masked]>
Date: Fri, 15 Apr 2005 12:11:13 +0100

Hi Frank,

I wasn't being so subtle :-(

When I wrote:

> 3. Does an Expected_Script[_Subtag] field always contain at
> least two Scripts?

I meant:

  3. Are there always at least two Expected_Script values?

There is a separate question of whether we're still using 
semicolons to separate values in the registry or whether we're 
repeating fields ... I've lost track of where we've got to on 
that.  If it is the former, then I'm suggesting, eg:

   Expected_Scripts: Hans; Hant; Bopo

If it is the latter, then I'm suggesting, eg:

   Expected_Script: Hans
   Expected_Script: Hant
   Expected_Script: Bopo

Misha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Frank Ellermann
Sent: 15 April 2005 00:15
To: [email-masked]
Subject: [Ltru] Re: Proposed Text for Moving Forward

Misha Wolf wrote:
 
> 1. Is an Expected_Script_Subtag field and a Default_Script
> field mutually exclusive?

No, the latter can be identified as "only one expected script"
The rules are of course very different, SHOULD vs, SHOULD NOT.

> 3. Does an Expected_Script[_Subtag] field always contain at
> least two Scripts?

Not if you combine them as in (1),  Probably that was your
real question, can they be used together for the same language.

-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo 

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

---

From: "Addison Phillips" <[email-masked]>
Date: Fri, 15 Apr 2005 07:42:59 -0700

No. 

Addison

Addison P. Phillips

> From: JFC (Jefsey) Morfin [mailto:[email-masked]]
> Sent: vendredi 15 avril 2005 01:41
> To: Addison Phillips; John Cowan; Mark Davis
> Cc: [email-masked]
> At 21:07 14/04/2005, Addison Phillips wrote:
> Interesting.
> Would you have by any chance a .doc or .pdf version available?
> thank you.

---

From: "Addison Phillips" <[email-masked]>
Date: Fri, 15 Apr 2005 10:11:26 -0700

I agree that the Gothic example might not be obvious, this would be a good place to put a comment into the registry.

It might be useful to actually distinguish between processing language and content language (metadata). For example, one might use "got-Latn" and "got-Goth" on <p> elements in an XHMTL document so that appropriate fonts can by applied to each in a stylesheet and still use "got" (meaning "got-Latn") in the <meta> element or in external references to the document. See: http://www.w3.org/TR/i18n-html-tech-lang/#ri20030510.102829377, which helped form my thinking about this.

I don't think that script associations need to pass an obviousness test. But the temptation to register every script a language has ever been written in should be guarded against since it will cause a lot of texts to pick up "SHOULD" when they really should not. Perhaps having separate fields (default and associated/expected) would help this, allowing promiscuous registration of associated scripts.

In that case, it is:

0*1[default_script] = SHOULD NOT
2*[default_script] = SHOULD always
[associated_script] = informational list of additional scripts???

Comments?

Addison

Addison P. Phillips

> Behalf Of Randy Presuhn
> Sent: jeudi 14 avril 2005 19:32
> To: [email-masked]
> Subject: Re: [Ltru] Re: Proposed Text for Moving Forward
> 
> Hi -
> 
> > From: "Addison Phillips" <[email-masked]>
> > To: "Frank Ellermann" <[email-masked]>; <[email-masked]>
> > Sent: Thursday, April 14, 2005 4:48 PM
> ...
> > Perhaps the rules should be:
> >
> > 1. If the primary language has no associated script,
> > you SHOULD NOT use a script subtag
> > unless it adds distinguishing information for that context.
> >
> > 2. If the primary language has a single associated script
> >  and the content uses that script,
> > you SHOULD NOT use the script subtag (unless etc.).
> >
> > 3. If the primary language has two or more associated scripts
> > and the content uses one of them,
> > you SHOULD use the script subtag (unless it is harmful to do so).
> >
> > 4. If the primary language has any number of associated scripts,
> > but the content uses a different script,
> > you SHOULD use the script subtag (unless it is harmful to do so).
> 
> To get the desired results for Gothic, (no subtag for Gothic transcribed
> into latin alphabet, subtag required if using the historical Gothic
> alphabet)
> I think this would mean that the entry for Gothic could not identify
> Gothic
> as an associated script, and that the associated script (if any) would be
> latin.  I guess this works, but I'd classify it as "obvious only if
> previously
> understood."
> 
> Randy
> 
> 
> 
>

---

From: "Peter Constable" <[email-masked]>
Date: Fri, 15 Apr 2005 18:52:44 -0700

On
> Behalf Of Misha Wolf

> 2. Why does Expected_Script_Subtag contain "_Subtag" but
Default_Script
> not do so?  Can we rename the former to Expected_Script?

First off, I'm not sure that we need *both* of these fields. But if we
are going to include "Expected_Script(_Subtags)", then I think
"_Subtags" should be part of the label. The reason is that without it
the meaning of the field isn't clear. The whole purpose for which the
field was suggested IIRC was to indicate those cases in which a script
subtag should be included in a tag (in contrast to those cases in which
a script subtag should *not* be included in a tag). "Expected_Script"
doesn't clearly convey that; indeed, someone seeing "Expected_Script:
Cyrl, Arab" might possibly interpret that to me Cyrillic can be assumed,
so they don't need to include "Cyrl" in a tag.

But I'm more inclined to communicate directly what we want users or
developers to understand -- in just which cases should a script subtag
not be included for general use -- and that is done most directly by a
single value listed in a "Default_Script" field.

Peter Constable

---

From: "Peter Constable" <[email-masked]>
Date: Fri, 15 Apr 2005 18:57:37 -0700

On

> Instead, we should create fields that exactly match what you do with
them.
> Subtag: en
> Suppress_Script: Latn

This approach addresses my concern: that we communicate clearly in what
cases a script tag should not be included in a tag for general use. This
field label communicates that better than "Default_Script" does.

Peter Constable

---

From: "Addison Phillips" <[email-masked]>
Date: Sat, 16 Apr 2005 12:18:57 -0700

I dislike "default" because it implies way too many things that aren't really true about the field. "Implicit" isn't bad, though.

Addison

Addison P. Phillips

> Behalf Of Peter Constable
> Sent: samedi 16 avril 2005 05:34
> To: [email-masked]
> > As a non English speaker I more or less understand the English of
> > "Suppress_Script" because I know its history. I am not sure an
> occasional
> > developper will understand/remember the meaning of it. Unneeded,
> needless,
> > redundant_script would be clearer to me.
> 
> Keep in mind, we do expect someone to have at least glanced at the RFC.
> But if "Suppress_Script" really doesn't communicate well enough, then
> what about "Implied_Script" or "Implicit_Script"?
> 
> 
> A side note: In a paper I wrote three years ago, I had a section
> entitled "Default values and implicit tagging", discussing specifically
> the issue of script subtags. I find it interesting that we started with
> a suggestion of a field called "Default_Script" and have now come around
> to a suggestion that it be called "Implicit_Script". FYI, here's an
> excerpt from the end of that section of that paper:
> 
> <quote>
> The choice of whether or not to adopt the use of implicit default
> semantics amounts to a trade-off between simpler tags and compatibility
> with existing implementations on the one hand, and identifiers with more
> predictable forms, more predictable semantics, and therefore no need to
> maintain a database of implicit relationships on the other hand.
> </quote>
> 
> 
> 
> Peter Constable
>

---

From: "Addison Phillips" <[email-masked]>
Date: Sat, 16 Apr 2005 12:29:33 -0700

I agree, Mark, that the full effect can be achieved with only one field and that your proposal is superior in a number of regards (fewer moving parts, ease of maintenance, ease of application).

I proposed two, though, for a reason. One of the objections was that we didn't document when a particular script really ought to be used (i.e. that you really should start to use zh-HanX-XX in preference to zh-XX). 

Notice where I put the stability guarantee: on the required scripts. Suppression of a script subtag is only stable as long as a language is only known to be written in one script (excepting oddities). Requirement of a script subtag however can be stable (no matter how many you add). Selection of a subtag, once selected, should be stable. The suppress field can't provide that.

The fact that you cannot turn the rules around using the required scripts (you still don't know when to omit a script subtag) lead me inexorably to two fields.

But I'd be just as happy, if not happier, with only one of these informative fields. The only option for that is the suppress field.

Addison

Addison P. Phillips

> Behalf Of Mark Davis
> Sent: vendredi 15 avril 2005 22:26
> To: Peter Constable; [email-masked]
> I'm sorry, I really misworded what I wanted to say, so it must have been
> very confusing.. In the opening, I meant to say that I don't see the
> reason
> for the *Require_Script*.
> If you look below, you see that what I propose is:
> 
> ...this could be simplified down to one
> field, Suppress_Script, and two rules.
> 
> 1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be used
> to form language tags unless they add specific information to the language
> tag required by an application.
> 
> 2. Script subtags not listed in the 'Suppress_Script' field SHOULD always
> be
> used to form language tags when the script used by the content being
> identified matches the script unless there is a specific reason to omit
> the
> script subtag in the application.
> 
> 
> So
> A. If the Suppress_Script is Latn, then en-Latn becomes en, while en-Cyrl
> stays as is
> B. If there is no Suppress_Script (say for zh), then zh-Hant, zh-Hans,
> zh-Cyrl, (and everything else) stay as is.
> 
> 
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "Peter Constable" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, April 15, 2005 19:03
> > Behalf Of Mark Davis
> > This is a real improvement. But in terms of results, it appears that
> there
> > is no real difference in guidance in having the Suppress_Script field,
> and
> > having nothing. So it is unclear why the 'Suppress_Script' is needed.
> 
> This is the most useful field: it is the one that addresses the concern
> voiced by Ira and others: that we don't get users or application
> developers going off and thinking that now they should use (say)
> en-Latn-GB or that the inclusion of Latn in this case has no particular
> concerns associated with it.
> 
> 
> 
> Peter Constable
> 
>

---

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 17 Apr 2005 12:14:04 -0700

-1

Ah, I see, we _are_ all wasting our time.

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> From: [email-masked] 
> [mailto:[email-masked]]On
> Sent: Sunday, April 17, 2005 3:08 PM
> To: Doug Ewell; LTRU Working Group
> I agree with you 100%, Doug, because I think that we have it 
> 180 degrees reversed.
> 
> The problem with default script, as you point out, is that it 
> puts the registry maintainers into a position of having to 
> adjudicate about a language's script. "en" is a very poor 
> test case because it is nowhere near an edge case. 
> 
> The problem is that registering a default script for a 
> language is like trying to prove a negative. Let's pick on 
> Serbian or Azerbaijani for a minute. Let's say someone tried 
> to register a default script for one of these. You could 
> point to all of the sr-Cyrl or az-Latn texts you want. That 
> doesn't prove the non-existence or non-importance of other 
> scripts for that language. I'm concerned that later 
> registrations might cause a need for general retagging and 
> that is BAD.
> 
> For the registry process to have meaning, I think that we 
> should stick to what is actually demonstrable: you can 
> register the fact that a language is commonly written in two 
> or more scripts because you can demonstrate that. This would 
> make the rules and design simpler and *also* make the entries 
> more robust. The rules would then be:
> 
> 1. Script subtags SHOULD NOT be used to form a language tag 
> unless they add some distinguishing information. For example, 
> the 'Latn' subtag is generally unnecessary with the primary 
> language 'en' because nearly all English documents are 
> written in Latin script.
> 
> 2. The script subtag SHOULD always be used to form a language 
> tag when the script of the tagged content matches a 
> 'Required_Script' field for the associated primary language. 
> For example, you should use the 'Hant' script subtag to form 
> the language tag "zh-Hant-TW", even though most Chinese 
> language documents in Taiwan are written in the Traditional 
> Chinese script. The 'Required_Script' field generally appears 
> in primary languages that are written in more than one script 
> and which might otherwise be ambiguous.
> 
> IOW, I added script suppression as a sop to default script, a 
> concept that is easy to understand and seems desirable, but 
> which may be difficult to maintain in practice (see all the 
> deprecated primary language registrations for examples of the 
> registration process being used in unproductive ways). 
> 
> Best Regards,
> 
> Addison
> 
> Addison P. Phillips
> > Behalf Of Doug Ewell
> > Sent: dimanche 17 avril 2005 01:05
> > To: LTRU Working Group
> > Addison Phillips <addison dot phillips at quest dot com> wrote:
> > 
> > > I agree, Mark, that the full effect can be achieved with only one
> > > field and that your proposal is superior in a number of 
> regards (fewer
> > > moving parts, ease of maintenance, ease of application).
> > >
> > > I proposed two, though, for a reason. One of the 
> objections was that
> > > we didn't document when a particular script really ought 
> to be used
> > > (i.e. that you really should start to use zh-HanX-XX in 
> preference to
> > > zh-XX).
> > 
> > I know I said I would back off and not get involved in the
> > default-script issue.  OK, so I lied.  Sorry about that.
> > 
> > AFAICT, this whole issue started with the concern that 
> people would use
> > a script subtag in cases where it was generally thought to be (a)
> > unnecessary, because the intended script would be obvious, and (b)
> > undesirable, because it would interfere with left-prefix 
> (RFR) matching.
> > 
> > The standard example was "en-Latn-US."  The case was made that the
> > overwhelming majority of written U.S. English text is written in the
> > Latin script, so the added flexibility of being able to specify the
> > script would be largely unnecessary, and in particular it would be
> > overshadowed by the inability of existing left-prefix matching
> > algorithms to match "en-Latn-US" with "en-US" (sometimes 
> generalized to
> > "broken backward compatibility").
> > 
> > This was the foundation of "default script": certain languages like
> > English could be listed as having a default script of 
> Latin, so that tag
> > generators could avoid creating tags like "en-Latn" or "en-Latn-US"
> > whose disadvantages would outweigh their advantages.
> > 
> > Of course, in certain circumstances you might have English 
> written in
> > Braille, or even in Cyrillic, and most if not all seemed to 
> agree that
> > in these rare circumstances it would be acceptable to generate
> > "en-Brai-whatever" or "en-Cyrl-whatever."
> > 
> > The standard counterexamples were "zh-Hans" and "zh-Hant."  
> The case was
> > made that Chinese is commonly written in both of these 
> script variants,
> > and it would often be beneficial to include script 
> information, to the
> > point of perhaps being more important than strict compatibility with
> > left-prefix matching algorithms.  Languages like Chinese 
> and Azerbaijani
> > and Serbian, after all, were the major use cases for the 
> introduction of
> > script subtags in the first place.
> > 
> > So unlike "en-Latn", it would not be discouraged to write 
> "zh-Hans" or
> > "zh-Hant", or either of these followed by a region subtag.  
> Of course,
> > just like English, Chinese could also be written in a less obvious
> > script like Braille or Cyrillic, and so "zh-Brai" and 
> "zh-Cyrl" ought to
> > be allowed as well.
> > 
> > I concede that because of the stated predominance of 
> processes that use
> > left-prefix matching, it might be beneficial to define a 
> default script
> > for common languages that are written in a single script 
> 99.9% of the
> > time.  I still don't know where the authority comes from to 
> decide which
> > languages and which scripts get marked in this way -- definitely not
> > from ISO or documented registrations or deterministic rules, like
> > everything else in the registry -- but I assume that would 
> be worked out
> > in due course.
> > 
> > What I do NOT understand is how this has expanded to 
> telling people when
> > they SHOULD use script subtags, and how the set of allowable subtags
> > should be limited in some way.
> > 
> > There may well be cases where "zh" or "zh-CN' or "zh-TW" is 
> all that is
> > needed, and there is certainly existing data that uses such tags.  I
> > don't see any justification for discouraging such usage, 
> even if we have
> > defined a way to tag Chinese data more precisely.  
> Likewise, if there is
> > no prohibition against writing "en-Brai" or "en-Cyrl", then I see no
> > reason to prohibit or discourage "zh-Brai" or "zh-Cyrl" either.  A
> > "required-script" field would do exactly this, by listing 'Hans' and
> > 'Hant' but not others.
> > 
> > This is too prescriptive.  It tells people how they SHOULD 
> tag data, not
> > just in terms of "tag content wisely" or "don't be 
> excessively precise,"
> > but on a specific language-by-language basis.  It assumes, 
> implicitly,
> > that this group or ietf-languages has the expertise and authority to
> > make this judgment.  Unlike default-script, required-script 
> does nothing
> > to solve the left-prefix matching problem, and as such, I 
> don't think
> > it's within the scope of the charter.
> > 
> > I propose the following:
> > 
> > 1.  An optional, informative default-script field that 
> would suggest to
> > tag generators that they not use that particular script 
> subtag together
> > with that particular language subtag.  This field could be added,
> > changed, or removed at any time.  (It doesn't matter much 
> what the field
> > is called, and I renew my suggestion that we not try to 
> inject too much
> > deep meaning into the names of fields, or assume that users 
> will derive
> > deep meaning from them.)
> > 
> > 2.  NO requirement within the draft that tag generators 
> "must not" use
> > script subtags in any given scenario.  The text in draft-01 that
> > discourages the use of a script subtag "unless it conveys additional
> > information" should be adequate.
> > 
> > 3.  NO mechanism to tell tag generators that they "should" 
> use a script
> > subtag together with any particular language subtag, and 
> *especially*
> > not one that lists the "expected" script subtags while 
> excluding others.
> > If tag generators opt to create a tag such as "zh-TW" that "may be
> > ambiguous without script information," that should be up to them.
> > 
> > -Doug Ewell
> >  Fullerton, California
> >  http://users.adelphia.net/~dewell/
> > 
> > 
> >

---

From: "Addison Phillips" <[email-masked]>
Date: Sun, 17 Apr 2005 16:27:22 -0700

Look, I'm happy *enough* with my low-cost, two-piece solution.

What turned you off? Was it that you found my logic below compelling or just that you didn't agree with the design below? If it is just the design, I can go with the original proposal. If it is the logic, then help me out here: what works? 

Consensus is good. I'm happy to take a design I don't like for some personal reason (I might be wrong in my reasoning, after all). But it should be the right solution for the problem, if possible.

Addison

Addison P. Phillips

> From: McDonald, Ira [mailto:[email-masked]]
> Sent: dimanche 17 avril 2005 12:14
> To: Addison Phillips; Doug Ewell; LTRU Working Group
> > [mailto:[email-masked]] On
> > > Behalf Of Doug Ewell

---

From: "Peter Constable" <[email-masked]>
Date: Sun, 17 Apr 2005 21:04:36 -0700

On
> Behalf Of Frank Ellermann

> We only want to get rid of an explicit Latn for languages like
> en, got, fy, or an explicit Cyrl for ru, etc.  That's why I
> don't understand the idea of more than one suppress_script for
> the same language, IMO that should not be allowed.

+1

Peter Constable

---

From: "Peter Constable" <[email-masked]>
Date: Sun, 17 Apr 2005 21:50:43 -0700

On

> Less convincing, in a hrefang= to a WAV or MP3 I don't need any
> Hans or Hant.

I'm not a proponent of the "Required_Script" field, but I'll observe
that this concern could be resolved by indicating that the script subtag
should be included when tagging *text* content/resources, not
non-textual content/resources.

Peter Constable

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 18 Apr 2005 15:36:32 +0200

+1
(with the provisio of my other remarks, that this implicit_script story is 
only for legacy)