Re: I18N-ISSUE-246: Clarify character encoding behavior when calculating storage size [ITS-20]

Hi all,

FYI, Yves and I yesterday joined the i18n call to move this issue
http://www.w3.org/2013/03/28-i18n-minutes#item04
and the line-break type issue
http://www.w3.org/2013/03/28-i18n-minutes#item05
forward. Yves volunteered to rephrase the passages in question for both 
issues
http://www.w3.org/International/track/issues/246
http://www.w3.org/International/track/issues/247

So he'll probably take this thread and the other one
http://lists.w3.org/Archives/Public/www-international/2013JanMar/0396.html
into account.

What took some time during the call was discussion about the purpose of 
ITS (1 or 2) in general: ITS is meant to transport metadata *values* to 
consuming applications. Here it is useful to have default values like 
"utf-8". But ITS does not define what the applications *do* with the 
values. You will see that with other metadata items as well. E.g. a 
"translate" attribute is not necessarily used for translation, but for 
creating pseudo text or an XLIFF package.

"Directionality" is another example of this: none of ITS processors 
mentioned at
http://htmlpreview.github.com/?https://raw.github.com/finnle/ITS-2.0-Testsuite/master/its2.0/testSuiteDashboard.html
don't render bidi text - they just transport the directionality values 
to e.g. an XLIFF package. This has also implications for testing, btw.: 
for directionality we don't test rendering, but just whether the correct 
identification of metadata values has been done. That is the 
pre-requisite for transporting the values.

This "metadata transport" function of ITS is quite useful IMO: it helps 
to create workflows with many tools: browser, various authoring tools, 
CMSs, translation mgmt tools etc. But you then cannot formulate 
something like "in an ITS processor implementing storage size, utf-8 
support is required", since the processor just conveys the information 
to whatever tool consumes it.

Best,

Felix

Am 29.03.13 11:56, schrieb Anne van Kesteren:
> On Fri, Mar 29, 2013 at 10:32 AM, Jirka Kosek <jirka@kosek.cz> wrote:
>> Rationale for this change is reflecting hopefully all raised concerns:
>>
>> -- UTF-8 encoding is a default value of storageEncoding attribute, so
>> there is no need to repeat this in a note
>>
>> -- It has been pointed out that storage size mechanism is targeted for
>> generating output resources that are loaded into various components and
>> devices. Many of such devices are legacy and do not support UTF-8 so
>> requiring UTF-8 support will not be aligned with the reality and will be
>> artificial requirement.
> Nevertheless, you could still add a note that encourages using it as
> it's the only encoding that's non-problematic going forward and ports
> across a wide variety of platforms. If there are still systems that do
> not support utf-8, they better start figuring out a migration story.
>
>

Received on Friday, 29 March 2013 11:37:41 UTC