Subject: RE: [Ltru] seeking resolution of the Great Script Debate

From: "Addison Phillips" <[email-masked]>
Date: Sat, 9 Apr 2005 17:52:49 -0700

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. 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.

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.

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. 

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:[email-masked]]
> 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.

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.

> 
> 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.

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.

> jfc
> 
> 
> On 00:20 10/04/2005, Addison Phillips said:
> >content-class: urn:content-classes:message
> >Content-Type: text/plain;
> >         charset="utf-8"
> >
> >It seems to me that in order to achieve a resolution of this issue, we
> >need to take a step back and look concretely at the problem.
> >
> >This message is going to be somewhat long, since I'm going to look at
> both
> >sides of the problem in detail.
> >
> >Let's start with the compatibility problem. The claim of Ned, Ira, and
> >others is that 3066bis "breaks" existing implementations. I think that
> >word "breaks" is problematic, because it does not describe accurately
> what
> >happens. No implementations actually crash when you send them tags that
> >they don't recognize (those that do are beyond consideration here). What
> >we mean is that the results produced are either not what the user
> expected
> >or are different than what the user previously received for the same
> request.
> >
> >There are two kinds of implementation that we've been holding up for
> >examination. I'll take them in turns.
> >
> >First are pure RFC 2616 matching implementations which don't care about
> >the contents of a particular subtag. This is equivalent to what 3066bis
> >calls a "well-formed" processor. Common examples of these include
> >xml:lang, CSS 2.1, Apache's language negotiation mechanism and Kurt's
> LDAP
> >RFC. In these implementations, it doesn't matter if you send them a tag
> >like "foo-bar-baz-gleep" or "zh-Hant-CN". All that matters is the
> matching
> >of each token or subtag in order.
> >
> >For these implementations, script subtags pose a problem if they are
> >inconsistently used for a given language prefix. That is, if I sometimes
> >request "xx-Latn-CC" and sometimes request "xx-CC" or if I sometimes tag
> >content using "xx-Latn-CC" and sometimes as "xx-CC", then I will
> >experience problems with matching the "xx-Latn" prefix to "xx-CC" and
> vice
> >versa. The approach 3066bis takes here is to suggest that content authors
> >and requesters be systematic in using or not using script subtags.
> >
> >Let us pause and recognize that there are many implementations of this
> >nature and also recognize that this is not by any means "all"
> >implementations either.
> >
> >Second are the kinds of implementations Ned Freed has described, which DO
> >care about the contents of specific subtags. In an RFC 3066bis
> >implementation, these are validating processors. A well-known example
> that
> >I'll use as a proof-of-concept is the ServletRequest.getLocale method of
> >J2EE. This method takes Accept-language tags in the HTTP header and
> >attempts to match them to java.util.Locale objects predefined in the Java
> >runtime environment. There are roughly 150 of these in a JRE (less,
> >usually, and the number varies by JRE) in the form
> language_region_variant.
> >
> >There are four ways that these implementations may react to a tag in the
> >form "xx-Latn-CC". First, they may find the language and region code and
> >ignore interstitial subtags (producing xx-CC in our example). Second,
> they
> >may find as many subtags in order until the meet one they don't recognize
> >(producing xx in our example). Third, they may reject the whole tag as
> >unrecognized. Fourth, they may assign wrong values to the wrong fields
> >(which produces the same results in many ways as option the second).
> >
> >Any of these is a valid reaction.
> >
> >It is certainly possible in the J2EE case for a user to set up all of
> >their content and resource bundles to work "correctly" with script
> >subtags, but it is significant work to do so. In addition, Locale objects
> >created with a script in either the region or variant slot will not work
> >correctly and probably return the default language for the particular
> >configuration or JRE.
> >
> >This is not an insignificant problem.
> >
> >In fact, ironically, I have a demo of this on my own website here:
> >
> >http://www.inter-locale.com/LocalesDemo.jsp
> >
> >Only... I wrote the AcceptLanguageBean class that powers this demo around
> >my RFC 3066bis implementation and it gets the right answer for
> >"zh-Hant-TW" (try it yourself).
> >
> >So I wrote one that uses pure J2EE here:
> >
> >http://www.inter-locale.com/bis.jsp
> >
> >It produces:
> >
> >Lang = zh
> >Region = Hant
> >Country = TW
> >
> >This is essentially the same thing as saying "zh" in terms of results.
> >
> >There isn't much that we can tell users to do with their content tags or
> >requests that will ameliorate this mismatch, since the implementation is
> >using values in the subtags to perform some kind of mapping or processing.
> >
> >This problem (in this example, but not, please note, all possible
> >examples) could be addressed by moving the script subtag down in the
> order.
> >
> >The problem is the mismatch between RFC 2616 matching's needs (see
> Misha's
> >email) and this J2EE-style matching's needs.
> >
> >Addison
> >
> >Addison P. Phillips
> >Globalization Architect, Quest Software
> >http://www.quest.com
> >
> >Chair, W3C Internationalization Core Working Group
> >http://www.w3.org/International
> >
> >Internationalization is not a feature.
> >It is an architecture.
> >
> >_______________________________________________
> >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: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 10 Apr 2005 04:56:43 +0200

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
>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.

>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.
>
>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.

>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).

> > 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

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Apr 2005 18:45:54 +0200

Addison Phillips wrote:

> XML doesn't *need* or *want* two ways to identify language.

But it has encoding and allows other meta-data, in the case of
XHTML I could use something like...

 <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
 <meta http-equiv="Content-Script-Type" content="text/javascript" />

...to define a script in addition to the old xml:lang= or lang=
language.

> it can't GET a new built in attribute that uses a URL or any

It also can't get a new built-in attribute for say the location
- but it's simple to add this meta-data where needed.

> (see: "the huge success of XML 1.1").

That's apparently a joke, without knowing what's going on I've
almost started a flame-war on the xml2rfc list only because I
dared (durst ?) test version="1.1".

> Locale identifiers for Web services can be URLs and may very
> well be. But they are orthogonal to this discussion.

Why ?  Maybe we should add scripts to the "charset" instead of
the languages.  Using Unicode everywhere caused this mess, so
it's only fair if they fix it, charset="UTF-8-mainly-Latn" or
whatever.
          Bye, Frank

---

From: "Jukka K. Korpela" <[email-masked]>
Date: Sun, 10 Apr 2005 20:33:10 +0300 (EEST)

> ...to define a script in addition to the old xml:lang= or lang=

No, those tags have nothing to do with specifying human languages or
scripts (writing systems) for writing them. It would take too much time to
explain all the conceptual errors involved, but the main point is that the
(pragmatically useless) second tag above specifies the _programming
(scripting) language_ used on the page.

> the languages.

The "charset" thing there is itself something that has been added to an
Internet media type, a parameter. It would be illogical to put extra
information into a parameter instead of using another parameter. Besides,
an Internet media type designation has its own role and purpose,
not including the indication of language or script.

> Using Unicode everywhere caused this mess, so

Are you serious? It's not 1st of April any more.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Apr 2005 19:58:48 +0200

Jukka K. Korpela wrote:
 
> those tags have nothing to do with specifying human languages

Of course not, that's why I said "something like".  For Bruce's
draft it could be "Content-Script".

> the (pragmatically useless) second tag above specifies the
> _programming (scripting) language_ used on the page.

Yes, I know this, and it's not useless, or how should a XHTML-
browser guess what I want with an onload="..." string ?  We're
on the wrong list for this question, but at least it should be
clear that I did not propose to replace text/javascript by Latn
or Brai.
 
> It would be illogical to put extra information into a
> parameter instead of using another parameter.

At the moment the draft adds extra information (script) to the
language, if that's a bad idea maybe adding it to the charset
is less illogical.  Maybe an independent parameter is better.

It's IMNSHO obvious that nobody needed it when the "charset"
was something like Latin-1.  It's only now after Unicode has
de facto eliminated these differences that we miss them and
want a script back, somehow, somewhere.

>> charset="UTF-8-mainly-Latn" or whatever.

It's the "Great Script Debate".  I didn't start it, so where
would you add the script after the "charset" degenerated into
the "ideally it's all Unicode" in HTML 4 and later ?

                      Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 10 Apr 2005 21:35:06 +0200

Frank, Jukka,
IMHO this debate started the wrong way with first a final proposition being 
proposed and progressively basic Charter issues emerging. I am a network 
man and not competent in external applications such as LDAP, XML, HTML, 
etc. I am somewhat interested in CLDR because it may add/interfere with the 
inner structure of a network operating system (NOS). I therefore tend to 
trust Addison as a W3C person when he speaks of XML. But obviously I am 
interested to understand the real XML lower level needs when they may 
relate with the NOS or with protocols.

 From what I understand from Addison, the intricacy of the XML system 
impeaches to think of another XML architectural solution? Your comments are 
really welcome, in the same way as Addison proceeded: discussing the cons 
and pros. (we cannot accept Jukka's "It would take too much time to explain 
all the conceptual errors involved" comment: we are here to specify network 
protocol related issues - and further as underlined by Jown Cohan - we are 
told to be dependent in XML demands. The least XML people can do is to 
document them).

Our own need is simple: the members of a user class "A" share a context "A" 
with a group of resources "A", our job as a CRC (context reference center) 
is to maintain and make accessible the data of this context "A" to all the 
participants to the "A" externet registered to the "A" registry. Such 
context may contain every information the "A" Members may decide to store 
there. We started with DNS root, PAD, reference links and work on tags and 
a language to describe/use the context elements. Some context elements 
could certainly be (like for example the various tables used for the tags) 
maintained through CRCD subscriptions (context reference compact disk) 
proposed by intelligent services providers and formatted updates 
(comparable to anti-virus support).

For example we can certainly conceive XML documents (or LDAP, etc.) 
including xml:lang=$langtag and the $langtag variable to be converted from 
a local context search or by an OPES/ONES acting on the page output/input, 
in taking care of the specifics of the concerned application. Our interest 
is not in format but in content. The content description and usage should 
be universal and the formats should be documented by the application 
designers. We are ready to best help, but not to the detriment of other 
general principles, equal and stable for everyone. The adequation of a 
format participates to the adequation and competitiveness of an 
application. The users are to chose on a network by the users for the users.
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Apr 2005 22:23:45 +0200

JFC (Jefsey) Morfin wrote:

> I am a network man and not competent in external applications
> such as LDAP, XML, HTML, etc.

Okay, what Addison said (my interpretation) was essentially
that we can't change XML 1.0 (or 1.1) as it is.  Numerous
formats based on XML exist (XHTML is only one example), they
won't learn new tricks like a xml:script only because we say
so in a hypothetical XML 1.2.

And of course XML is W3C, not IETF, so we'd be in the wrong WG,
unless Martin and Addison would start some very complex rituals
with their hats => dead end, no XML 1.2, it cannot help.

OTOH all document formats based on XML are free to add their
own attributes, e.g. XHTML 1.0 has its own "lang" (inherited
from HTML) in addition to the "xml:lang".

But it's the same problem with existing formats like HTML 4.01
or XHTML 1.0, they won't learn new tricks in the form of new
attributes only because we say so.  A hypothetical new HTML 4.1
or XHTML 1.0.1 is a very dubious idea.

It would be really nice if we could squeeze the script somehow
in the existing language tags.  But if Ned says NO because he
knows a case where it would cause harm it's a serious problem.

Jukka said that adding it to the charset is a horrible idea -
that's of course true, but if we can't add it to the language
we're stuck.

> we cannot accept Jukka's "It would take too much time to
> explain all the conceptual errors involved" comment

That was probably only a misunderstandig, he feared that I
don't know what a Content-Script-Type is, because he's used to
some obscure charset="windows-1252" proposals from me on the
validator.W3 list. ;-)  And I'm used to his "why XHTML if HTML
is better" comments on the same list, so maybe it was a joke.

Or I didn't understand it, whatever, it's irrelevant for the
Great Script Debate.

> we are here to specify network protocol related issues

Actually we are here to specify a new language tag registry.

Debbie said, that she would like another dimension "charset"
in these crazy tags, but now we're looking at solutions without
script (less dimensions).  Nothing promises to be the "best for
all" solution.  That forces us to find the least harmful exit.

Please drop the idea to abuse DNS to get combined language tag
registry entries, at least not in a form languages * scripts *
regions * variants, that's horrible.
                                    Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 11 Apr 2005 01:44:22 +0200

Dear Frank,
I understand that the X(HT)ML applications have debate enough on the matter 
to permit this WG to feel free about them, as long as it fullfils its 
Charter assigned role to permit a consistent solution.

>Actually we are here to specify a new language tag registry.

If we can make the proposed language tag registry useful outside of the 
Internet standard process, all the best. But this is the IETF and we are 
concerned by protocols, procedures and best common practices.

>all" solution.  That forces us to find the least harmful exit.

I do not think we are boud to a least harmful exit. Experiences in that 
area like IPv6, IDNA, etc. did not result into something really appealing. 
I think we can certainly find a good, stable and innovative for all solution.

>regions * variants, that's horrible.

May be could you comment that more in detail? In the way you understand it. 
Thank you.

I do not think my idea is to abuse DNS. I documented our need. I documented 
our solution. I did not document yet our information dissemination 
strategy. I need to understand first what Addison has to explain. I suppose 
we also need more involvement in this WG. As Addison explained it well, if 
you do not involve/hurt the people who may oppose you, you will upset them 
and you will never get their support.

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 11 Apr 2005 05:18:35 +0200

> May be could you comment that more in detail? In the way you

I do NOT understand you.  You wanted to replace "-" by "." in
the 3066bis tags, but 1766 & 3066 use "-".  You had a problem
with "--" because it's used in certain IDNA labels, but Doug
only used "--" like the HH in 3166-3 (= "no single successor"),
Doug's "--" has nothing to do with any 3066bis language tag.

Finally you repeated weird calculations languages * scripts *
regions * variants, I've not the faintest idea what you were
talking about, but you kept mentioning "DNS" in this context.

So I guessed that you plan to build something like a tag tree,
maybe translating all possible language-script-region-variant
into some variant.region.script.language.jefsey.example RRs (?)

If that guess was wrong just ignore it.

> I documented our need. I documented our solution.

Please stop the pluralis majestatis TINW "our", what solution
are you talking about, is it a standard or RfC, or is it your
CD ROM with some IANA registries ?  If it's the latter just
copy the future IANA registry as is, and don't explode it into
a languages * scripts * regions * variants tree with numerous
bogus leaves like zh-Cans-BU-scouse.

                          Bye, Frank

---

From: "Jukka K. Korpela" <[email-masked]>
Date: Mon, 11 Apr 2005 08:33:39 +0300 (EEST)

> from HTML) in addition to the "xml:lang".

Indeed, and some relevant recommendation could even suggest that
_if_ you implement something in XML, then you should do it in
a such-and-such a way, like using a particular attribute name.
But you could not easily make a new attribute part of the xml namespace
("part of XML itself", to speak loosely).

> knows a case where it would cause harm it's a serious problem.

There's the possibility of specifying script separately and not
fixing how that information is stored and sent. After all, language
codes too can be used in a multitude of ways.

> don't know what a Content-Script-Type is

Well, maybe in part that too, but basically I was afraid the discussion
would take us to side paths that lead nowhere. For example, <meta>
tags aren't really the way to specify language or charset or content type,
so I missed the point in using them as (or in) arguments in this
discussion looked off.