AW: Call for consensus - storageSize and displaySize

Hi Yves, all,

I'm still confused about storage size. In my understanding: If I state a storage size limit in bytes than I'm done. I would interpret this limit as: Whatever content you put here, it shall not exceed the maximum number of bytes. Whether I use encoding A or B should be irrelevant, since the I have to ensure that my text using my encoding does not exceed the byte limit. I think, one would only need the additional encoding attribute if we would base storage on character counts. Or is this a totally wrong understanding?

Cheers

Michael

________________________________________
Dr. Michael Kruppa, Senior IT-Consultant 
Tel.: +49 69 972 69 189 Fax: +49 69 972 69 204; E-Mail: michael.kruppa@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

dmexco 2012 in Köln: Besuchen Sie unseren Messestand auf der internationalen Leitmesse für die Digitale Wirtschaft am 12. und 13. September 2012. Sie finden uns in Halle 7, Stand E057.
dmexco 2012 in Cologne: Come to see us on September 12 and 13 at the Digital Marketing Exposition and Conference (hall 7, stand E057).



-----Ursprüngliche Nachricht-----
Von: Yves Savourel [mailto:ysavourel@enlaso.com] 
Gesendet: Freitag, 24. August 2012 16:58
An: public-multilingualweb-lt@w3.org
Betreff: RE: Call for consensus - storageSize and displaySize

Hi Michael,

> In yesterday’s call I understood, that storageSize should simply 
> depict the maximum byte size of a particular content (not only the 
> translated one but also the original one).
> If this is so, I do not quite understand why we should need the 
> attribute storageEncoding in this data category?
> Could somebody please explain this to me? If not, can we simply drop 
> the storageEncoding attribute?

The encoding is needed because the place where the storage limitation is does not necessarily use the same encoding as the environment where we limitation is verified.

For example: the max size may be for a string extracted from a db table where the encoding is ISO-8859-1, so there a character 'é' would take 1 bytes, while the document may be verified in an environment where UTF-16 is used. Most applications nowadays work with Unicode characters not bytes. So the tool need to know how what encoding to use to go from the characters to the bytes.

Making it mandatory may even be better: it would force users to think about what they are doing.


> Secondly, we have been discussing about the displaySize attribute. I’m 
> not 100% sure what the purpose of this data category is. Could 
> somebody please explain what it means, what are typical use cases and 
> whether it should be based on character or byte counts?

Personally I think specifying a maximum display size is too complex to be defined in the time we have. Having something that works with only characters was ok when most UI where "curses"-like. Nowadays, fonts need to be taken into account in many cases and that make things very difficult to standardize. I'd drop that data category.

-ys

Received on Saturday, 25 August 2012 19:04:40 UTC