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

RE: Constraints Types and Values

From: Yves Savourel <ysavourel@translate.com>
Date: Mon, 10 Oct 2005 17:07:15 +0200
To: <public-i18n-its@w3.org>
Message-Id: <20051010150754.20A8832978@smtp4-g19.free.fr>
Good point Christian.
We would have to work out exactly the values and expected behavior for this, and see how much this overlap (or not) the xml:space


From: Lieske, Christian [mailto:christian.lieske@sap.com] 
Sent: Monday, October 10, 2005 4:26 PM
To: public-i18n-its@w3.org
Cc: Yves Savourel
Subject: 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,


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. 
Received on Monday, 10 October 2005 15:08:05 UTC

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