Message-Id: <6.1.2.0.2.20050410030855.0471b3e0@mail.jefsey.com>
Date: Sun, 10 Apr 2005 04:56:43 +0200
To: "Addison Phillips" <addison.phillips@quest.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] seeking resolution of the Great Script Debate
In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.c
 om>
References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@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 02:52 10/04/2005, Addison Phillips said:
>In a word: yes, it would be a HORRIBLE problem to have two different 
>language tags in the same document that do the same thing

Dear Addison,
Why two different language tags in the _same_ document?
The choice would have been between the "xml:lang" and "xml:nlang"? But I 
will wait for Monday to understand.

Yet, we need a context tag anyway, which will include the elements of the 
language tag since a context can much wider and necessarily includes the 
language elements.

>And it isn't possible for XML and its relatives to adopt another scheme 
>anyway. Language tags in W3C document formats must be compatible with 
>xml:lang (meaning RFC 3066's 1*8ALPHANUM *["-" 1*8 ALPHANUM]) or they will 
>be a failure before they even start.

Okay you know better what XML does. But beware that what we currently work 
on is to study and further on document a much much wider need (all what two 
interlocutors may think they share in common). We are not interested in any 
specific application, but in networking. But I suspect that XML users will 
want to use them.

Right now we are interested first in ASN.1 to document formats under 
various systems including XML and our own Gositer multilingual exploratory 
system, and in convergence with other technologies (phone, MPEG, etc).One 
of the first issue is a universal numbering scheme permitting to access the 
context data directly through a stable IPv6 address. Just remember that we 
approach the networks in a user centric way, very pragmatic. The network of 
the people by the people technology.

>I am getting to writing the email in which I demonstrate that the issue I 
>document isn't so large as I made it appear. You'll have to wait for 
>Monday for that one.

No problem. Thank you.

>The reason that XML and CSS and other document formats don't go off and 
>ignore 3066 in favor of an improved scheme is the same reason Randy's 
>suggest that we create a bunch of orthogonal headers is a bad one. Tagging 
>content with language becomes balkanized. Users must create both new 
>attributes in their documents and new headers in the transmission formats 
>and populate both and keep the various bits synchronized. Further more, 
>headers in HTTP (for example) refer to tags in document formats such as 
>XHTML. These items necessarily refer to one another.

This is your area. Not mine. Mine is all this is to work on a network which 
cannot support all this without either balkanizing what we do not want, or 
drasticically enhance in seriously supporting classes and groups (not just 
a single "Internet" class and a pseudo Chaos class). I have no idea yet how 
an application will be able to take advantage from such an evolution. (When 
you started your RFC 3066 bis effort you interrupted my own effort to 
document how IETF could tackle the Multilingual Internet documentation: it 
started with the description of the request of IAB guidances on a certain 
numbers of key points).

This is also why I am glad of the new IESG Chair, as his RFCs on the 
Internet architecture are clear, open and full of experience.

>There is no need for this confusion to take place. Language tags are 
>extensible in many ways without breaking most RFC 3066 implementations 
>(and only harming the remaining 3066 implementations in very specific, 
>relatively benign ways---but again, you have to wait for Monday for why I 
>think it's benign).
>
>Some more below.
>
>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: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com]
> > Sent: samedi 9 avril 2005 17:07
> > To: Addison Phillips
> > Cc: ltru Working Group
> > Subject: Re: [Ltru] seeking resolution of the Great Script Debate
> >
> > Addison,
> > I may be dumb stupid. But I see that you honnestly document a problem
> > which
> > results from a change in the format of the entry in a function. I have
> > some
> > difficulty understanding why do you want to do that?
>[Addison Phillips]
>
>Because the first step in gaining support for consensus compromise is 
>documenting both sides honestly. If I show that I acknowledge and 
>understand issues raised by Ned, et al, then it is likely that they'll not 
>be feeling attacked while I discuss why I think our solution is the best 
>one available and why I think that the situation is not so dire.

My question was why do you want to enter a new format in an old function. 
But I appreciate all this as quite positive.

>What you document is
> > that the current functions work well with the current tags. But if you
> > change them to work well with the new tags, they will not to work well
> > anymore with old tags what seems to make sense.
>[Addison Phillips]
>
>No, I did NOT document that. Old tags work perfectly with new processors. 
>Every time. The new (3066bis) processors are much better than the old ones 
>when dealing with and detecting corner cases.
>
>The problem is that some old processors that "look inside" tags and expect 
>(wrongly in the case of J2EE: notice that J2EE doesn't even LOOK at the 
>value it crams into the region code) that a specific position maps to a 
>specific value creating a situation in which slightly or mostly wrong 
>content is supplied in response to a request.
>
>Send "i-klingon" to J2EE and you get language "I" and region "Klingon". 
>Bad stupid.
>
>Thankfully, that locale matches the nearest actual locale in Java 
>supporting that tag--which is the empty locale!
>
>In Java the request "xx-ssss-cc" would match the actual locale "xx" 
>instead of the locale "xx-CC" when "xx" is a supported language. Bad, but 
>not completely stupid.

Okay. XML, HTML and I suppose CLDR, at least are your show.

> > Why not just to do as Jesus said: to have new functions for new tags and
> > to
> > keep old functions for old tags? Is this a very big problem for W3C to say
> > that xml:lang will keep using the old tags format and that xml:nlang will
> > use a new format built from experience? Since you say libraries will have
> > to be updated and no one is using yet your new format, the update would
> > only to add nlangtag support to existing langtag support? By the same
> > token
> > you could also announce the support of xml:xlang to support the extended
> > language tag we need.
>[Addison Phillips]
>
>XML doesn't *need* or *want* two ways to identify language. Furthermore, 
>it can't GET a new built in attribute that uses a URL or any other format 
>(see: "the huge success of XML 1.1"). Language tags in W3C document 
>formats will be 3066-compatible tags for essentially forever.

Okay if you say so. Problem is that the format you propose 2/3 chars - 4 
chars - 2 chars is not enough to support what we need. So we will need 
another system which will also identify languages. And that system may not 
directly use subtags to stay stable (cf. Charter).

>Locale identifiers for Web services can be URLs and may very well be. But 
>they are orthogonal to this discussion.
> > Question (I am not at all an XML person):
> > - would this be a big problem if the xml:*lang tag was an URL?
>[Addison Phillips]
>
>See above.
>
> > - would this be a big problem if the language parameters were documented
> > in another more extended way?
>[Addison Phillips]
>
>Yes. How may XML implementations are there already? Count all technologies 
>that use XML in them. It is not possible for it to be adopted. There is a 
>firm requirement for a compatible scheme.

This is I suppose the main difference we have. I consider that langtags are 
the first building block of a Multilingual Internet. And that MI is a 
totally new network architecture (yet fully based upon and compatible with 
the ASCII Internet). So, there are three areas to consider:

- where you need your langtags. You know where, I dont - and I do not fully 
understand what you do with them.
- where one does not need your langtags (or not necessarily): you added web 
services to the list - good news as one of my main concern was OPES and web 
services interintelligibility. Are you considering Word processors etc. in 
the same case as XML or  as Web Services?
- where Multilingual Internet features may be considered/defined first to 
provide a stable, compact, open one shot container.

I will carefully read your Monday explanation.
Have a nice WE.
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru