W3C home > Mailing lists > Public > public-i18n-its@w3.org > April to June 2006

RE: Action Item: http://www.w3.org/2006/04/20-i18nits-minutes.html#action08 (process="no" flag)

From: Lieske, Christian <christian.lieske@sap.com>
Date: Tue, 25 Apr 2006 16:20:19 +0200
Message-ID: <0F568FE519230641B5F84502E0979DD104F38498@dewdfe12.wdf.sap.corp>
To: "Felix Sasaki" <fsasaki@w3.org>, <public-i18n-its@w3.org>

Hi Felix, all, 

Good input. Please find some comments interspersed (marked as "CL>") in
Felix' mail. Bottom-line seems to be:
The proposal I made wasn't a good one.

I wonder if we should not move down the path of an additional data
category. I could imagine to have one which
might be called "localize". It would be similar to the existing
"translate" data category but would have to
define a different default selection.

Best regards,

-----Original Message-----
From: public-i18n-its-request@w3.org
[mailto:public-i18n-its-request@w3.org] On Behalf Of Felix Sasaki
Sent: Dienstag, 25. April 2006 07:17
To: Lieske, Christian
Cc: public-i18n-its@w3.org
Subject: Re: Action Item:
http://www.w3.org/2006/04/20-i18nits-minutes.html#action08 (process="no"

Hi Christian, all,

Lieske, Christian wrote:
> Hi there,
> Here's my proposal (which could for example be added to the
> n).
> Best regards,
> Christian
> ---
> In certain cases, it is necessary to attach ITS information to element
> nodes (as opposed to text nodes). 

I think this should not be "element nodes", but "element or attribute


> An information architect may for
> example have to express that all images (which in his XML vocabulary
> referenced via an "src" attribute on an "img" element) should not be
> translated.

This is only terminology, but saying "images should (not) be translated"
sounds strange to me. What do English native speakers think?

CL> I agree. 
>>From the point of view of ITS selection, this requirement poses a
> challenge since the default selection of the ITS data categories and
> use of XPath do not cater for the attachment mechanism that is needed.
> ITS masters the challenge in a fashion which is similar to XSD

this is a very dangerous comparison! Using "processContents" in XML
Schema means that you don't validate elements or attributes.
"processContents", as you define it, means that *additional* information
is attached to elements and attributes, besides translatability

CL> I understand your concerns.

: The
> introduction of a specific "its:processContents" attribute. A value
> of "no" for this attribute instructs ITS processors that no processing
> is necessary. 

that is not the case! The value "no" is a value *in addition* to
"translate yes" or "translate no". What you mention as processing is
beyond the scope of ITS, i.e. it is s.t. which happens *after* what we
define as ITS processing:
[[Processors need to compute the ITS information which pertains to a
node in an XML document. The ITS processing expectations define how the
computation has to be carried out. Correct computation involves support
for selection mechanism, defaults, and precedence. ]]
. We have to be very careful what we talk about.

CL> Good point.

> This way, ITS allows the declaration of information
> without enforcing its processing.

again, that s.t. is not processed, is not the scope of ITS processing.

> The example below exemplies how "its:processContents" can be used with
> "its:translateRule" in order to attach ITS information to various
> aspects of graphics:
> - The first two "its:translateRule" specify that the values/text of
> "src" and the "alt" attributes have to be translated, and that the ITS
> processor needs to attach the ITS translate data category to the
> corresponding nodes. 
> - The third "its:translateRule" specifies that the graphics (the "img"
> element) has to be translated as well. The "its:processContents="no",
> however, tells the ITS processor that it does not need to attach the
> translate data category to the corresponding nodes.

I'm confused by your example: I would have expected the third rule to be

<its:translateRule its:selector="/img/@src" its:translate="yes"

with your selector attribute "/img": how does an application know that
the external object which should not be processed can be found via the
@src attribute?
Yves writes at http://www.w3.org/Bugs/Public/show_bug.cgi?id=3126 :
[[Nothing works for the objects associated the //img/@src]]
so I think the selector attribute should be "/img/@src".

> <text>
>  <head></head>
>   <its:rules>
>    <its:translateRule its:selector="/img/@src" its:translate="yes"/>
>    <its:translateRule its:selector="/img/@alt" its:translate="yes"/>
>    <its:translateRule its:selector="/img" its:translate="yes"
> its:processContents="no"/>
>   </its:rules>
>  <body>
>   <img src="w3c_home.png" alt="W3C"/>
>  </body>
> </text>

There are various concerns mentioned at
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3126 :
[[Additional notes (with richard, after Christian had to leave the
Not sure such solution would work as it cannot be applied to muliple
categories at the same time locally. May have to use specific new data
(e.g. translateObject). Note that using such mechanism locally does not
for attributes (no selector) so this reduce the usability.]]

In addition, I am wondering how inheritance / precedence works. How
a1) <its:translateRule its:selector="//img" its:translate="yes"
a2) <its:translateRule its:selector="//div/descendant-or-self::*"
if you imagine that <img> is part of <div>: do we assume that no
processContents attribute means "processable"? if the answer is yes:
would a2) have higher precedence than a1)? if "yes", I would need to
change the order of rules so that a1) wins, but that might to lead to
problems like:
b1) <its:translateRule its:selector="//div/descendant-or-self::*"
b2) <its:translateRule its:selector="//img" its:translate="no"
here, b2) has not only a different value for process content, but also
for translatability. If I don't want to give both a higher precedence
than b1), I am in trouble.

My current conclusion: I am very concerned that we will not be able to
think this all out in the next weeks. I see the value of this, but not
the time to design it clearly ... How about keeping it for ITS 1.1?

Regards, Felix.
Received on Tuesday, 25 April 2006 14:20:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:04:09 UTC