W3C home > Mailing lists > Public > public-i18n-its@w3.org > October to December 2005

RE: Constraints Types and Values

From: Lieske, Christian <christian.lieske@sap.com>
Date: Mon, 10 Oct 2005 16:26:15 +0200
Message-ID: <0F568FE519230641B5F84502E0979DD103C58CC4@dewdfe12.wdf.sap.corp>
To: <public-i18n-its@w3.org>
Cc: "Yves Savourel" <ysavourel@translate.com>
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,


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

=== 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

=== 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> >.

That's all I have so far. 
Received on Monday, 10 October 2005 14:26:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:06 UTC