Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt

From: "Addison Phillips" <[email-masked]>
Date: Tue, 12 Apr 2005 16:07:27 -0700

My response probably wasn't that clear.

Script is not intimately related to charset in a number of interesting cases. Such as Unicode cases. Adoption of Unicode character encodings does increase the need to identify script (since the charset attribute cannot be a surrogate for it). 

Script *is* related to language identification in cases where a specific "language" can be written in more than one script. Simplified vs. Traditional Chinese, for example.

This is only "two pieces of information" if you actually want to select script separately (orthogonally) from language. What are the use cases for this? When do you select text in 'Hant' in which you don't care about the language? Conversely, when do you render text in (say) 'Latn' but the individual language is not also important.

Users needing to identify different attributes of text (script, language, orthography, etc....) will have to separately identify each of these attributes in conjunctions with one another. This greatly increases the complexity of what should be a simple task.

Legacy data formats cannot represent a separate attribute without being modified. Legacy data must be retagged under the 3066bis design, of course, to obtain the benefits of the new design. But this can be done incrementally and only in cases where the script is actually a differentiator. 

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 Randy Presuhn
> Sent: mardi 12 avril 2005 15:41
> To: LTRU Working Group
> Subject: Re: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt
> 
> Hi -
> 
> > From: "Addison Phillips" <[email-masked]>
> > To: "McDonald, Ira" <[email-masked]>; "Randy Presuhn"
> <[email-masked]>; "LTRU Working Group"
> <[email-masked]>
> > Sent: Tuesday, April 12, 2005 3:12 PM
> > Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt
> >
> 
> > Script is not useful if the charset is UTF-8 (for example). It is quite
> useful in certain cases with language.
> ...
> 
> I don't understand this comment.  I don't see
> how the use of UTF-8 changes anything regarding the utility
> of script tags.
> 
> Perhaps I'm reading too much into the proposal, but I thought
> the heart of the idea was while that a script is not an intrinsic property
> of a language, it is useful, in conjunction with language, in marking and
> selecting content.  The question is whether it's better to represent these
> two pieces of information in a single tag or two tags, with the arguments
> pro and con being about interpretation of legacy data, tagging of new data,
> behavior of legacy applications, impact on existing standards which don't
> already provide for this kind of tagging, and evisioned future uses.
> 
> Randy
> 
> 
> 
> 
> _______________________________________________
> 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: "Randy Presuhn" <[email-masked]>
Date: Tue, 12 Apr 2005 16:51:15 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, April 12, 2005 4:07 PM
...
> Script *is* related to language identification in cases where a specific
> "language" can be written in more than one script.
> Simplified vs. Traditional Chinese, for example.
>
> This is only "two pieces of information" if you actually want to
> select script separately (orthogonally) from language.

This depends on how you think about legacy data, legacy applications,
and matching.  Sometimes the information is absent from the data,
sometimes it's absent from the query.  How to interpret this absence
has been problematic, and it *seems* harder when we try to combine
the bits into a single string.  Of course, in an information-theoretic sense,
there's no difference, but when we speculate about existing data and
existing applications dealing with new data, there could be a big difference.
I'll be relying on the judgement of application implementors here.

> What are the use cases for this?
> When do you select text in 'Hant' in which
> you don't care about the language?

Not terribly useful to me, but I would like requests for Cantonese
that did not specify a script to produce Cantonese documents regardless of
whether they were marked as traditional, simplified, IPA transcription,
or bore no script identifier at all.   Some of the alternatives discussed do this
with the various combinations of new and legacy apps with new and legacy
data, some don't.

Likewise, I'd like requests for specific varieties of German language,
both in the formulation of the request and the selection of the results,
to not be made overly complicated by whether I did (or didn't) care
which orthography was in use.

> Conversely, when do you render text in (say) 'Latn'
> but the individual language is not also important.

Rendering is not the problem, as far as I know.

> Users needing to identify different attributes of text
> (script, language, orthography, etc....) will have to separately
> identify each of these attributes in conjunctions with one another.
> This greatly increases the complexity of what should be a simple task.

I agree, and that's why I'd hardly call myself a strong advocate of this
view.  It appeals to the linguist and programmer in me, but it does not
seem to be aligned with how users view things.

> Legacy data formats cannot represent a separate attribute without
> being modified. Legacy data must be retagged under the 3066bis design,
> of course, to obtain the benefits of the new design.

This is what I think we'd all like to avoid or at least minimize,
but it may be nothing more than a hope.

> But this can be done incrementally and only in cases where the script
> is actually a differentiator.
...

This is true whether script is encoded as part of the language tag or as a
separate field.  For me personally the deciding factor will be the question
of how well encoding it as a single string will work with existing applications,
without hamstringing future ones.  That's where the application implementors'
perspectives are especially important.  If they are convinced they can make
it work, I'll be very happy.

Randy