Message-Id: <6.1.2.0.2.20050410044608.047d1a70@mail.jefsey.com>
Date: Sun, 10 Apr 2005 04:55:31 +0200
To: ned.freed@mrochek.com
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] Compatibility with existing use (LDAP)
In-Reply-To: <01LMWG2NCBKW00005R@mauve.mrochek.com>
References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com>
	<001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer>
	<01LMWG2NCBKW00005R@mauve.mrochek.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

Ned,
you are most probably right about LDAP and Addison about XML. But this is 
not the case for _new_ services like OPES (open pluggable edge services: 
intelligence on the edge of the network, able to change the langtag of an 
XML page at will before it receives it) or my own long delayed ONES (open 
network extended services: intelligence (virtually in an end to end 
architecture) within the network we see coming back. This not true about 
the architectural solutions to support multilingualism. Even SMTP can be 
dramatically affected through the charter of the WG-OPES on SMTP support 
(even if we are quite delayed by the same problem as this WG: to understand 
how to support at the same time the past, the present and the future).

jfc


On 03:44 10/04/2005, ned.freed@mrochek.com said:
> > As a technical contributor, the longer this thread goes on
> > the more consideration I think we should give to alternatives like
> > http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt
>
> > If we were to treat the identification of the language(variant),
> > the script, and the orthography of a text as three distinct
> > attributes, rather than trying to structure them into a single string
> > called a "language tag" would it ultimately make things simpler
> > or more complicated?
>
> > I find this approach intuitively appealing in the case where there are
> > multiple orthographic alternatives in the same script for a
> > given language, yet it has no impact at all on texts in languages
> > where identification of the script or orthography in use is of
> > no particular interest.  Even transcriptions and transliterations can
> > be handled nicely into this kind of approach, since they just become
> > orthographic alternatives.
>
> > It would, however, require a re-thinking of how we've handled
> > German and Chinese.
>
>No doubt there's some appeal to this idea, but I don't think it's practical.
>
>The single biggest implementation problem I see right off is that language 
>tags
>are used in lots of places, at least one of which is not amenable to the
>addition of separate script field. I'm referring, of course, to XML. I believe
>adding an xml:script field to go along with xml:lang could only be done with a
>major revision to the XML base specification. And even if such a change could
>be made, getting it deployed would be a real challenge.
>
>Other cases, like email, would be able to add a content-script: field much 
>more
>easily, of course. Even so, a vast amount of code would have to be changed to
>actually make use of this new field.
>
>LDAP is another interesting case. Language tags in LDAP are actually a 
>specific
>case of a more general mechanism. But AFAIK little use is made of attribute
>tags for purposes other than language tagging. This calls into question how
>general the mechanism actually implemented by various clients and servers
>actually is.
>
>And even if you were to get the field defined in every place where there's a
>field for language tags, you still have to actually make use of the field.
>Having two separate fields certainly makes it easy to recognize script 
>tags and
>prevents them from causing problems in the language tag space, but you lose
>information relating language to scripts. For example, suppose you have:
>
>     content-language: az, ru, en
>     content-script: latn, cryl
>
>It stands to reason the Russian is written in cyrillic and the English in
>latin, but what script is the Azerbaijani text written in?
>
>Of course you could require a 1:1 correspondence between the entries in 
>the two
>fields, but that would then require a way to indicate when the script is
>unknown. And tags would have to be repeated since a single script can apply to
>multiple languages or vice versa. Ick. This is _seriously_ ugly. And even if
>you ignore the ugly, the repetition of tags in language fields is certain to
>cause problems to existing software.
>
>So, much as I would like to eliminate the interop problems the current
>proposal for adding script codes causes, I really don't think this is
>a viable way to do it.
>
>                                 Ned
>
>P.S. My linguistic skills are rudimentary at best, but my recollection is 
>that
>Azerbaijani is a language that can be written in either cyrillic or latin
>script. If that's not the case please substitute a language where this is
>actually true in the above example.
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru