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

Initial thoughts on "Generic approach for Contraints"

From: Lieske, Christian <christian.lieske@sap.com>
Date: Fri, 11 Mar 2005 18:36:35 +0100
Message-ID: <0F568FE519230641B5F84502E0979DD102672FFE@dewdfe12.wdf.sap.corp>
To: <public-i18n-its@w3.org>

Hello,

During yesterday's confCall we discussed the idea of a generic approach
towards handling all sorts of constraints (e.g. related to container
size). I took the action item to elaborate. Please find my initial
thoughts below. They do not only touch constraints but some additional
thoughts we already exchanged as well.

I apologize in advance for not being able to participate in any possible
immediate discussion related to this. I will be on vacation for some
days.

Best regards,
Christian
---
Design time tools, runtime engines, workflow related to software
production sometimes place constraints/requirements on the data/code
that is produced. Examples:

1. necessity to encode message strings in 7-bit ASCII
2. length restriction for an item in a drop-down list
3. requirement to capitalize the text in a menu entry
4. the marketing-related directive not to localize a product name

It is not unlikely that these constraints have to be known to people and
applications related to the localization or translation of data/code.
Accordingly, the constraints have to be communicated or transferred
efficiently.

A generic approach for the communication of constraints could be gleaned
from what has been done in the realm of cascading stylesheets (CSS). CSS
provides a number of mechanisms for communicating mostly style-related
information. Several features of CSS might be worthwhile looking at:

1. location of information

CSS allows three locations for placing information

a. inline attached to elements (for example: <p style="color:red">)
b. centrally attached to data instance/document (in <style
type="text/css">...</style>)
c. centrally but externalized (and e.g. referenced as <link
rel="stylesheet" type="text/css" href="formats.css">)

2. naming scheme

CSS features a naming scheme which categories style properties. All
background-related information is for example prefixed by "background":

background
background-attachment
background-color
background-image
background-position
background-repeat

3. addressing

In CSS, so-called selectors can be used to associate information with
particular pieces of content. "div > p" for example designates all "p"
elements
appearing in a "div" element.

4. mechanism and rules for combination

CSS allows to combine information from different locations (see above).

Communication of constraints with an internationalization tag set could
work similar to the communication of style-related information with CSS.
One example of an inline constraint which follows these ideas is given
below. It combines thoughts on constraints with some of the ideas we
already discussed wrt. localization directives. The main vehicle here is
the provision of the span-like element "loc".  

<h1 id="101">Introduction to
	<loc="
		Obj-type:term;
		reference-termBase:'urn:myCompany:termBase:ProductX';
		reference-conceptID:43;
		reference-termID:65;
		note-forlocalizer:'Check the term base for a possible
update';
		action-translate:no;
		constraint-allowedchars:ASCII-7;
		constraint-maxwidth:20;
		constraint-widthUnit:char;
	">
	Document Management
	</loc>
</h1>

The example tries to capture several things

1. some of the categories (by means of a naming scheme based on
prefixes):mentioned in
http://lists.w3.org/Archives/Public/public-i18n-its/2005JanMar/0028.html
2. some of the properties listed in Yves' book (pages 148 ff)
3. a possibility to attach information to terms (by naming a
concept-oriented term base, a concept identifier and a term identifier);
the value 'term' for 'Obj-type' from my understanding could be further
specified along the lines of ISO 12620

The comparison with CSS only occurred to me when I started writing, so I
am not sure whether I should have brought this idea into the open so
quickly. Hopefully, however, its helpful since it may enable us to draw
on work already done
Received on Friday, 11 March 2005 17:37:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:12:44 GMT