W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > August 2012

RE: Call for consensus - storageSize and displaySize

From: Yves Savourel <ysavourel@enlaso.com>
Date: Fri, 24 Aug 2012 08:58:23 -0600
To: <public-multilingualweb-lt@w3.org>
Message-ID: <assp.0583630f3e.assp.0583427d4f.000a01cd8209$05c2a010$1147e030$@com>
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.

Received on Friday, 24 August 2012 14:59:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:51 UTC