W3C home > Mailing lists > Public > www-international@w3.org > January to March 2013

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

From: Yves Savourel <ysavourel@enlaso.com>
Date: Wed, 30 Jan 2013 05:23:30 -0700
To: <public-multilingualweb-lt-comments@w3.org>
CC: "'www-international'" <www-international@w3.org>
Message-ID: <assp.07427ce1f5.assp.0742914f33.003501cdfee4$9d063240$d71296c0$@com>
Hi Stephan, Norbert, all,

Sorry I missed looking at the text before. I have two small corrections:

- the property applies to the content (source or translation, not just its translation)
- the limit is a maximum (thus inclusive -> s/shorter/not longer/)

This would make the text:

==>
The storage size is expressed in bytes and is provided along with the character set encoding, and optionally the line break type, that will be used when the content will be stored. In order to check if the content will fit inside the storage limit given by storageSize, it has to be calculated whether the byte sequence that results from encoding this content is not longer than the given limit. This byte sequence is to be produced using the specified encoding (and possibly line break type).
<==

-yves


From: Stephan Walter [mailto:stephan.walter@cocomore.com] 
Sent: Tuesday, January 29, 2013 5:34 AM
To: public-multilingualweb-lt-comments@w3.org
Subject: Re: I18N-ISSUE-246: Clarify character encoding behavior when calculating storage size [ITS-20]

Dear Norbert,
 

this concerns issues 106 [1] and 107 [2] which you reported on the draft specification of the ITS 2.0 Tagset Standard.
 
At our last working group meeting we had a discussion on the topic. We came to the conclusion that the specification need not impose any requirements on implementations regarding supported character encodings, behavior on encoding problems or representation of line breaks.
 
In the context addressed by your issues this was not intended. The storageEncoding and lineBreakType will enable an implementation to make use of the storageSize information in a sensible way. The details of how this information is used are however up to the implementation.  We agreed to make this clearer by adding  a clarification to the end of the definition of Storage Size (8.21.1) as follows:
 
===
The storage size is expressed in bytes and is provided along with the character set encoding used to store the content.
 
==>
The storage size is expressed in bytes and is provided along with the character set encoding, and optionally the line break type, that will be used when the content will be stored. In order to check if the translation of the content will fit inside the storage limit given by storageSize, it has to be calculated whether the byte sequence that results from encoding this translation is shorter than the given limit. This byte sequence is to be produced using the specified encoding (and possibly line break type).
===
 
Would you agree that this answers the questions raised in your issues in an appropriate way?
 
Best regards
 
Stephan Walter
 
[1] https://www.w3.org/International/multilingualweb/lt/track/issues/106, http://www.w3.org/International/track/issues/246

[2] https://www.w3.org/International/multilingualweb/lt/track/issues/107, http://www.w3.org/International/track/issues/247

________________________________________
Dr. Stephan Walter, Senior IT-Consultant 
Tel.: +49 69 972 69 x Fax: +49 69 972 69 x; E-Mail: stephan.walter@cocomore.com 
Cocomore AG, Gutleutstra├če 30, D-60329 Frankfurt
Internet: http://www.cocomore.de Facebook: http://www.facebook.com/cocomore Google+: http://plus.cocomore.de
Cocomore ist aktives Mitglied im World Wide Web Consortium (W3C) und im Bundesverband Digitale Wirtschaft (BVDW)
Cocomore is active member of the World Wide Web Consortium (W3C)
Vorstand: Dr. Hans-Ulrich von Freyberg (Vors.), Dr. Jens Fricke, Marc Kutschera, Vors. des Aufsichtsrates: Martin Velasco, Sitz: Frankfurt/Main, Amtsgericht Frankfurt am Main, HRB 51114
Received on Wednesday, 30 January 2013 12:24:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 12:24:05 GMT