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

ITS: Constraints Types and Values

From: Yves Savourel <ysavourel@translate.com>
Date: Mon, 10 Oct 2005 09:16:04 +0200
To: <public-i18n-its@w3.org>
Message-Id: <20051010071643.AF7D528C8F@smtp3-g19.free.fr>
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

That's all I have so far.
Received on Monday, 10 October 2005 07:16:50 UTC

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