RE: Constraints Types and Values

Hi Yves,
 
What about handling of white spaces? One could argue for example "The
necessity to keep all white space in place is a constraint".
 
Best regards,
Christian

________________________________

From: public-i18n-its-request@w3.org
[mailto:public-i18n-its-request@w3.org] On Behalf Of Yves Savourel
Sent: Montag, 10. Oktober 2005 09:16
To: public-i18n-its@w3.org
Subject: ITS: Constraints Types and Values



Hi all, 

I had a pending action item from the face-to-face meeting of gathering
the different possible constraints and their possible values.

>From the viewpoint point of internationalization/localization I found
three types of possible constraints: 

=== Container size 

Usually related to a display (how wide and tall the display box is).
This constraint can be expressed in the following properties:

- max-width 
- max-height 
- min-height 
- min-width 
- size-unit: Unit in which the max-width, min-width, max-height, and
min-height are expressed. The possible values for these would be: char,
pixel, point, dialog-unit.

If the size-unit is pixel, points, or any font-related unit, we would
need also information about the font used for the display (family,
point-size, bolded, etc.)

This constraint seems to be a presentation issue that, while causing
certainly issue during localization, cannot be directly related to XML
data storage. Following the concept of separation of data storage from
presentation, I would say we should not try to implement this type of
constraint.


=== Buffer length 

The buffer length constraint is not a display-related issue, but an
indicator for storage (i.e. buffer in the software that reads the XML
resources, or a column size in a database).

This constraint could be expressed with the following properties: 
- max-length 
- length-unit: Unit in which the max-length is expressed. The values
would be: byte and char. 
- encoding: If the length-unit is byte we need extra information: the
actual encoding to use. 

Possibly, a additional min-length attribute could be useful too. The
only example I can thing of would be when a database field cannot be
null. In any case having min-length does not cause any additional
difficulty.


=== valid characters 

The last type of constraint I could think of is the list of valid (or
invalid) characters for the value of a node. This could be expressed in
the following properties:

- valid-chars 
- invalid-chars 

This constraint specifies what characters are allowed or not allowed in
a given content/value. For example filenames, strings used in a firmware
where font usage is limited (e.g. allow only Katakana and ASCII).

The value itself could be inspired from the CSS unicode-range descriptor
<http://www.w3.org/TR/REC-CSS2/fonts.html#descdef-unicode-range
<http://www.w3.org/TR/REC-CSS2/fonts.html#descdef-unicode-range> >.


That's all I have so far. 
-yves