RE: Constraints Types and Values

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
attribute.
 
-ys


  _____  

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