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

Mandelieu Proposals - Comments Christian

From: Lieske, Christian <christian.lieske@sap.com>
Date: Thu, 2 Mar 2006 14:26:19 +0100
Message-ID: <0F568FE519230641B5F84502E0979DD104A48C9E@dewdfe12.wdf.sap.corp>
To: <public-i18n-its@w3.org>

Hi Felix, Yves and all,

I've been through the proposals and here are my thoughts:

Summary:

proposal-01: need discussion
proposal-02: need discussion
proposal-03: agree
proposal-04: need disucssion
proposal-05: need discussion
proposal-06: need discussion
proposal-07: agree
proposal-08: agree
proposal-09: agree


Notes:


> ************
> proposal-01: have only one data category per <documentRule> element
> ************
--> need discussion

I understand the rationale but would like to discuss the observation
that
this is different from the approach which for example is taken by CSS
(one single element or attribute holds the information).


> ************
> proposal-02: use instead of <documentRule> elements with data category

> specific names
> ************
--> need discussion 

See comment on proposal-01. In addition: Might it be slightly more
difficult
to extend the coverage for more datacategories?

> ************
> proposal-03: create a child element <locInfo> for global localization 
> information
> ************
--> agree

An element of course would help to include localization-relevant info
for
"locInfo" (see Felix' reply to Yves).

> ************
> proposal-04: have an attribute @its:locInfoRef for localization 
> information globally / locally
> ************
--> need discussion

I like this in principal. However, I would like to discuss the
possibility
to point into the very same XML instance. My gut feelings tells me that
this
type of referencing should be part of the source text in the first place
(that is: When a translator needs to know "see also" via locInfoRef into
the text, then the reader may also need to know).

I usually advice against a connotation like "The URI can be accessed"
(for example a database) since usually issues like authentification and
authorization come into play.

Of course, I guess we should remove the reference to German humour :-)

> ************
> proposal-05: Separating the tasks of globally identifying+adding 
> ITS information to XML nodes, versus globally identifying+mapping 
> data categories to XML nodes. Having a set of "map" attributes (e.g.
> @its:translateMap") for the mapping task.
> ************
--> need discussion

I share Yves' thoughts.

I like the tri-partition (identify, add, pass through) which Felix has
introduced in his reply to Yves.
However, I have got the feeling that we talked about "selecting" rather
than "identifying" in the past.
Furthermore, I sth. like "dirPassThrough" rather than "dirMap" may
capture the semantics more clearly.

> ************
> proposal-06: Use the existing conformance levels 
> of W3C Ruby, and have one additional one.
> ************
--> need discussion

I would like to learn why the intermediate level would not show up the
the core Ruby spec.

> ************
> proposal-07: add to the precedence rules a rule for 
> "Selections inherited from other local usages of ITS markup"
> ************
--> agree

> ************
> proposal-08: add xml:lang as a data category, to be able 
> to map various language attriutes to xml:lang
> ************
--> agree

I suggest to include xml:space as well.

> ************
> proposal-09: Give up the schemaRule element
> ************
--> agree

I obfuscately once asked about the necessity to have both, documentRule
and schemaRule.

Cheers,
Christian
Received on Thursday, 2 March 2006 13:27:00 UTC

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