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

Editors' teleconference Summary for the Mandelieu Proposals

From: Yves Savourel <ysavourel@translate.com>
Date: Fri, 10 Mar 2006 12:57:42 -0700
To: <public-i18n-its@w3.org>
Message-ID: <002101c6447c$e4908db0$8f05a8c0@Breizh>

Hi all,

Felix, Diane and I had the editors teleconference on Friday. We look at the list of proposal from Mandelieu. This email summarizes
also some changes to the proposal discussed after the face-to-face meeting, when Richard and Felix met at the Unicode conference
this week.

In short: it's the latest proposals.

Also, we think that it would be good to have the specification draft publish again as soon as possible with the changes we end up
agreeing on in the coming weeks. So we have an intermediary specification before the last call draft coming after April.

I've try to summarize the 9 proposals (in their possibly modified state) here. I'll also include comments from different people.
Please correct me if I make any misinterpretation.

For reference the original proposals are here:

Proposal 01: Have only one data category per <documentRule> element.
Proposal 02: Use specific element instead of <documentRule> elements with data category.

We think these two proposals go together. They would allow to have better validation as each rule element could have different
attributes/elements specialized for a given data category. Some attributes would be shared across rules when they have the same
function (like the 'selector' attribute).

Example: we would have for instance:

 <its:translateRule its:selector="//notrans" its:translate="no" />

Instead of:

 <its:documentRule its:translateSelector="//notrans" its:translate="no" />

Nothing would change for the local its:translate attribute.

Christian comments (Proposal 01): 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).

Christian comments (Proposal 02): Might it be slightly more difficult to extend the coverage for more data categories.

Proposal 03: Create a child element <locInfo> for global localization information.

The idea is to avoid to put text in attribute when possible. We would have:

 <its:locInfoRule its:selector="//p">
  <its:locInfo>Some localization information</its:locInfo>

Instead of:

 <its:documentRule its:locInfosSelector="//p"
  its:locInfo="Some localization information" />

Yves was wondering why not using directly <its:locInfoRule> to hold the text, but he sees the wisdom of his 'elders' now: It is
cleaner and does not close the door for potential extension in <its:locInfoRule> (just in case).

Proposal 04: Have an attribute @its:locInfoRef for localization information globally/locally

The idea is to provide support for an alternative way to add localization information. This does not change the other attributes, it
simply adds a new feature. It could be used in a global rule:

 <its:locInfoRule its:selector="//joke"
  its:locInfoRef="http://www.example.com/klingons#humor" />

And it could be used locally:

<joke its:locInfoRef="http://www.example.com/klingons#humor">
 Three man went to a pub: a Klingon, ...

Christian comment: I like this in principal. However, I would like to discuss the possibility to point into the very same XML

Felix possible solution: You could have a fragment identifier for that purpose, e.g. <its:locInfoRule its:locInfoRef="#somePoint" />

Yves additional notes:

- Whatever the semantic of the value of its:locInfoRef is decided to be, it would be good to harmonize it with the value for
its:termRef (or conversely).

- Adding its:locInfoRef opens the possible case of having two notes for a single node, for example:

<joke its:locInfoRef="http://www.example.com/klingons#humor"
 its:locInfo="Be extra careful translating or adapting this humour.">
 Three man went to a pub: a Klingon, ...

In such case what are the processing expectations for these two notes. Felix proposes to not allow to use two notes at the same

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.

After comments, and further discussions it seems there is the start of a consensus that 'mapping' would make sense only for some
data categories, but not all. So, we would have:

- No mapping for: translatability, terminology, and directionality.
- Mapping for: localization information, ruby, and language identification.

--- localization information

A new its:locInfoMap attribute, used only in global rules. For example:

 <its:locInfoRule selector"//joke" its:locInfoMap="@note" />
<joke note="Be extra careful with translating or adapting the joke.">
Three man went to a pub: a Klingon ...

Christian had some comments on the original Proposal 05. They have no been copied them here since the proposal is quite different
now and they may not apply any more. Christian will make corrections if need.

--- ruby

See the Proposal 06 for the proposed ruby markup and discussion.

--- language identification

See Proposal 08 for this new data category and discussion.

Proposal 06: Use the existing conformance levels of W3C Ruby, and have one additional one.

We do not have, in the current draft, a real solution for global rule for ruby. Based on additional discussions between Yves and
Felix it seems the mapping would address this, but using a single rule (not several as described in the original Proposal 06). We
would have:

 <its:rubyRule its:rubyMap="//ruby"
  its:rubyBaseMap="rubyBase" its:rubyTextMap="rubyText" />
 <rubyText>World Wide Web Consortium</rubyText>

The value for its:rubyMap would be an absolute XPath expression while the ones for its:rubyTextMap and its:rubyBaseMap would be
XPath expressions relative to the node pointed by the value of its:rubyMap.

And for people who want to use the ITS ruby locally, we would keep the current markup we have with only a simple change of element

 <its:rt>World Wide Web Consortium</its:rt>

Instead of:

 <its:rubyText>World Wide Web Consortium</its:rubyText>

As for the "conformance levels", we are all eagerly waiting for Richard's summary and proposal.

Yves note: Also why we don't have support for <rp> and complex ruby?

Proposal-07: Add to the precedence rules a rule for "Selections inherited from other local usages of ITS markup"

Felix tried to explained the issue with the current precedence rules, but Yves could not get it yet. Some document examples
illustrating the problem would be a good thing to have.

Proposal-08: Add xml:lang as a data category, to be able to map various language attributes to xml:lang.

The idea is to provide a way to map language identification to xml:lang and possibly offer mapping for other existing markup with
similar semantic. This would be a data category with only a mapping attribute and it would be implemented as global rule only, for

 <its:languageRule its:selector="//*" its:languageMap="@myLangAttribute"/>

Yves notes from after the editors teleconference: I have several worries with the implementation of this:

- Most of the time the selector will be "//*" and that is very expensive to process.

- In addition to values, xml:lang has scoping and inheritance expectations. I assume they will be the same for the mapped markup.
But it makes the implementation very much more difficult.

- It does offers a way out for not use xml:lang. This is a bit comparable to the situation where its:translateSelector used
"in-situ" was offering a way out to put text in attribute, in our early drafts.

In addition Felix was considering an additional proposal to have a 'locale identifier' data category that would allow to map to the
concept of locale rather than language, allowing to separate the two concepts.

Proposal-09: Give up the schemaRule element.

There is no apparent opposition to this.

That's it.
Received on Friday, 10 March 2006 19:59:01 UTC

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