Message-Id: <6.1.2.0.2.20050414015539.0ceb6d50@mail.jefsey.com>
Date: Thu, 14 Apr 2005 02:05:34 +0200
To: "Addison Phillips" <addison.phillips@quest.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] Re: Moving Forward
In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B08D1E0@irvmbxw01.quest.c
 om>
References: <634978A7DF025A40BFEF33EB191E13BC0B08D1E0@irvmbxw01.quest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ltru Working Group <ltru@ietf.org>
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

On 00:44 14/04/2005, Addison Phillips said:
>Subtags which are not important for distinguishing content in an 
>application SHOULD NOT be used to form language tags. In particular, you 
>MUST NOT use the script subtag unless (a) the language subtag has an 
>Expected_Script field or (b) the specific script distinction is important 
>to the application. For example, the tag "en-Latn-US" should be used 
>exceedingly rarely since nearly all English texts are written in the Latin 
>script and it is generally not important to filter out those few that are 
>not, while documents that use the primary language subtag 'sr' (Serbian) 
>must be distinguished by the choice of Latin or Cyrillic script.

Even me, I understand what you mean. But I am afraid it does not make a 
difference for a parser developer? The parser is a piece of logic, not of 
comparative information. That something only occurs one time, or even 
should not occur or all the time: it must be supported? Or am I wrong?

To respond your question.

1. you are stuck with an XML design bundling bug. You try to make a 
feature. I think you should make it a temporary feature (to assume legacy 
and transition) and to fix the bug. Please consider that even if _you_ 
think genuinely it is a feature, the experience of this tiny WG already 
shows various ways to understand it: you will never prevent developpers to 
workout "better" solutions (a one to one, tag/parameter, approach will 
always be considered as more flexible). Unless you have a very strong 
documented rationale to bundle langtag's elements and the cacapcity to 
preach to developers, you _are_ eventually to support langtag, scriptag, 
countrytag, etc..

2. For your XML bundling bug: your 2-4-2 tag seems a well conceived 
temporary patch which will work until you have given XML the extensibility 
it needs. Unbundling, free format.

3. your solution should be part of the second document. The general 
guidelines to structure application oriented formats should be discussed in 
the first documen, with other language tag framework issues. The responses 
given to Ira shows the direact relation between the tag format and the filter.

jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru