ITS WG Collaborative editing page
Follow the conventions for editing this page.
Status: Initial Draft ie. please focus on technical content, rather than wordsmithing at this stage.
Author: Yves Savourel
Indicator of Container Size
This page is now generalized in the "Indicator of contraints": 
[CL] Following the ideas laid out in http://lists.w3.org/Archives/Public/public-i18n-its/2005JanMar/0043.html, and looking at Martin's remark that we may have to tackle many constraints/addiitional information, I suggest to rename the requirement to sth. like "Encoding of Constraints".
[CL] For each constraint, it should be possible to encode at least: the constraint itself, and the "motivator/setter" for the constraint. What I mean "motivator/setter" is the following: a certain constraint (e.g. container size) may only hold for a certain tool wihtin the overall processing chain. Thus, the important thing about the constraint is to ensure that the constraint holds when data is passed to that particular tool. Accordingly, a specific tool "sets" the constraint. When data is passed between other tools of the processing chain, the constraint may not be relevant.
Where fixed sizes are used for containers or objects (such as tables, table cells, frames, buffers, screens, images, etc.) a standard method should be used for indicating the dimensions of the container so that localization tools can automatically recognize them.
[MD] Are these restrictions on a single item, or are they the same on all items of the same type (e.g. all <menu> items,...)? (My guess is that there are several cases.)
Are the restrictions the same for all languages? I can immagine that while one tries to keep it that way, sometimes certain markets may just absolutely require higher resolution. What would be the way to handle that.
This helps the localizers to ensure that the content will fit as text expands in translation or if graphics need to be adapted.
This can also be used by localization tools to verify size restriction related to the implementation of the application where the content is used. For instance, to check that a translation does not overflow a buffer, or a display area.
For example, the content of the following <string> element must accommodate the length restriction imposed by the small display panel where it is used:
XSD (XML Schema Part 2: Datatypes Second Edition) provides a mechanism to define "Constraining Facets" (http://www.w3.org/TR/xmlschema-2/#rf-facets) that may provide some solution for this requirement.
Sometimes the size constraint may need to be expressed in a unit different from the unit used in the document. For example, The maximum length of a string may need to be expressed in byte or pixels instead of character.
[MD] I think the term "display cell" may often be helpful in this context. We might be able to refer to the Unicode TR about (East Asian) width, at least for some cases of this (sorry, currently offline).
This might lead to the possible requirement of being able to specify additional information (e.g. encoding, font, etc.) along with the size constraint. [Do we want to go there???]
[MD] I don't want to go there, but I guess we might have to go there :-(.