Re: Mandelieu Proposals

Hi Yves,

Many thanks for your comments. Here are some initial thoughts.

proposal-03:
I would propose a separate element, since this could have all attributes
which are used for local ITS, like the its:span element. Having these
attributes directly at the its:locInfoRule element would make it very messy.

proposal-05:
I see your point that the "mapping" proposal does not give new
functionality for the data categories translatability, directionality,
and ruby. I see new functionality for localization information,
terminology and the xml:lang category.

Here is a new try to distinguish the various functionalities:

1) "identify" usage of all data categories: realized by having the
element with the data category name and the selector attribute:

translatability: <its:translateRule its:selector="//*"/>
localization information: <its:locInfoRule its:selector="//*"/>
terminology: <its:termRule its:selector="//qterm"/>
directionality: <its:dirRule its:selector="//*"/>
ruby base: <its:rubyBaseRule its:selector="//odf:rubyBase"/>
ruby text: <its:rubyTextRule its:selector="//odf:rubyText"/>
xml:lang: <its:langRule its:selector="//*"/>

All these rules just say "the selected nodes are related to a data
category". This usage makes sense for terminology (it makes clear "this
is a term")and ruby (it makes clear "this is base text, this is ruby
text"). For the other categories, additional information is necessary.

2) "add information" usage of some categories. This is what we already
have in the draft.
translatability: <its:translateRule its:selector="//*" its:translate="yes"/>
localization information: <its:locInfoRule its:selector="//*"
its:locInfoRef="someURI"/> (there could also be a its:locInfo child element)
terminology: <its:termRule its:selector="//qterm" its:termRef="someURI"/>
directionality: <its:dirRule its:selector="//*" its:dir="ltr"/>

3) "pass existing textual content trough".
localization information: <its:locInfoRule its:selector="//*"
its:locInfoContent="xyz:locInfo"/>
terminology: <its:termRule its:selector="//qterm"
its:termRefContent="@someTermReference"/>
xml:lang: <its:langRule its:selector="//*"
its:langContent="@someLangAttribute"/>

I have used here the name "content" instead of "map", since this
functionality is I think what we achieved with the its:locInfoContent
attribute.
I think it depends how important 3) is for us, whether we want "map" (or
"content") attributes in the case of localization information,
terminology and xml:lang.


So much for today.

Cheers,

Felix


Yves Savourel wrote:
> Hi Felix and all,
> 
> I've been through the proposals and here are my thoughts:
> 
> Summary:
> 
> proposal-01: agree
> proposal-02: agree
> proposal-03: need discussion
> proposal-04: agree
> proposal-05: need discussion
> proposal-06: need discussion
> proposal-07: need discussion
> proposal-08: need discussion
> proposal-09: agree
> 
> 
> Notes:
> 
> 
>> ************
>> proposal-01: have only one data category per <documentRule> element
>> ************
> --> AGREE
> I like the idea of using a unique selector attribute. I also see some advantages to group data categories in the same <documentRule>
> (<its:documentRule its:selector="//qterm" its:translate="no" itsTerm="yes"/>) but I can see also that would make validation more
> difficult.
> 
> 
>> ************
>> proposal-02: use instead of <documentRule> elements with data category 
>> specific names
>> ************
> --> AGREE
> 
> 
>> ************
>> proposal-03: create a child element <locInfo> for global localization 
>> information
>> ************
> --> NEED DISCUSSION
> I like it to move the text to an element. But any reason to not put the text directly into <its:locInfoRule> instead of creating a
> new element? Also: what will be the content of this element since I assume it must be able to hold bidi-elements and possibly other
> formatting elements. Will we just allow '##any' elements? Or its:span only? Is this content translatable or not? if not shall it
> have a its:translate or shall it be defined as not-to-translate in ITS specs?
> 
> 
>> ************
>> proposal-04: have an attribute @its:locInfoRef for localization 
>> information globally / locally
>> ************
> --> AGREE (but not eagerly)
> This makes processing locInfo a bit more difficult to implement. (can a URI point to a non-XML resource?)
> 
> 
> 
>> ************
>> 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
> 
>> Example of the need to separate mapping and adding information:
>> <its:documentRule its:dir="ltr" its:dirSelector="//*[@dir='ltr']"/> 
>> is not mapping, it opens the door for errors (via the repitition 
>> of "ltr" in both attribute values)/>
>> instead, we propose for mapping separate mapping attributes, one 
>> for each part of a data category:
>> <its:dirRule its:selector="//*" its:dirMap="@dir"/>
> 
> I'm a bit skeptikal here: why this opens the door for errors? Because the selector attribute would contain a value? (shorter
> expression less prone to mistake?) If it's the *only* reason I think it's not enough to justify a whole new mechanism, especially if
> the 'old' mechanism can still be used when values are different.
> 
> My concern here is that we introduce a new type of process for the implementation. Now we would have to add some extra processing to
> deal with mapped markup.
> 
> I think I see the conceptual difference between what you acll 'adding' and 'mapping', but to me 'mapping' seems to be just a
> sub-case of 'adding' where the values of the ITS datacat markup and the value of the host language markup happened to be exactly the
> same.
> 
> When you 'add', you assign ITS information to the document. When you 'map' you assign document-specific information to the defualt
> ITS behavor from the veiwpoint of the processor, therefore you force the processor to be a bit less 'generic', hence more difficult
> to implement. Since you can get *exactly* the same result by only 'adding', I don't see the need for 'mapping'.
> 
>> The attribute for mapping contains a relative location path (relative 
>> to the nodes which are selected by the its:selector attribute). 
>> It would not be enough to have only one XPath in the selector 
>> attribute, as in the case below:
>> <span class="ruby">...
>> <its:documentRule selector="//span" rubyTextMap="@class='rt'"> 
>> (the span elements are identified by the XPath expression n the 
>> selector attribute. The mapping to its:rubyText is done via the 
>> XPath expression in the rubyTextMap attribute)
> 
> I don't think this resolev ruby: we need more than rubyText anyway: there is the <rp> element too. How do you 'map' it without
> adding another attribute?
> 
>> Benefit: People who already have ITS related markup in their schema 
>> (e.g. "translate" attribute in DITA, ruby in opendoc), can be 
>> convinced to adopt ITS not by changing their schema, but by making 
>> the semantics of their existing markup declarations clear with the 
>> separate documentRule element.
>> <its:documentRule its:selector="//*"
>> its:translateMap="@dita:translate"/> (saying "dita:translate" has the 
>> semantics of "its:translate")
>> <its:documentRule its:selector="//odf:ruby" its:rubyMap="."/> 
>> (saying "the odf ruby element has the semantics of the its:ruby element")
> 
> I don't quite agree: This is not a justification for separating 'mapping' and 'adding'. This works for any <documentRules>
> mechanism, whether it's the current 'adding' or the proposed 'mapping'.
> 
> 
>> Wide spread adoption of ITS becomes easier.
> 
> Bunkum and Claptrap! :)
> Using <documentRule> makes it easier, not 'mapping' (since 'mapping' is a sub-case of 'adding').
> 
> 
>> Sebastian: it makes a specific assertation that it is really 
>> identical .. useful e.g. if you just want to use the elements / attributes 
>> in your own namespace .. as it stands, you can make formally clear 
>> that this is identical ..
> 
> OK, that's the only real difference (other than conceptual) I can see between 'mapping' and 'adding'. But it seems very limited (to
> attribute-based datacat like 'translate' most likely), as for something like ruby, we could already use more complex XPath
> expressions, just like when 'adding'.
> 
>> processing of "mapping" does not mean adding extra nodes
> 
> Same for 'adding'.
> 
> 
>> Scenario: People want to say "my markup relates to an ITS data 
>> category", but they do not want to use ITS values. Tasks for ITS:
>> identify, map. Example:
>> <xyz:p xzy:translate="yes">...</xzy:p>
>> <xyz:p xzy:translate="no">...</xzy:p>
>> <documentRule its:selector="//xyz:p" its:translateMap="@xyz:translate"/>
>> (this means "xyz:translate has the meaning of the translatability 
>> data category; I 'trust' that the values of xyz:translate fit as well")
>> Benefit: There is no need to "pollute" your namespace with ITS markup.
> 
> Same with 'adding'.
> 
> 
> 
>> ************
>> proposal-06: Use the existing conformance levels 
>> of W3C Ruby, and have one additional one.
>> ************
> --> NEED DISCUSSION
> 
> I'm not sure I understand the example where we have three <documentRule> for the same ruby datacat (below):
> 
>> We can use the mapping mechanism to describe that this both 
>> has the same meaning:
>> <its:documentRule its:selector="//odf:ruby" its:rubyMap="."/>
>> <its:documentRule its:selector="//odf:rubyBase" its:rubyBaseMap="."/>
>> <its:documentRule its:selector="//odf:rubyText" its:rubyTextMap="."/>
> 
> 
>> ************
>> proposal-07: add to the precedence rules a rule for 
>> "Selections inherited from other local usages of ITS markup"
>> ************
> --> NEED DISCUSSION
> 
> 
> 
>> ************
>> proposal-08: add xml:lang as a data category, to be able 
>> to map various language attriutes to xml:lang
>> ************
> --> NEED DISCUSSION
> 
> Interesting. I can see a possible parallel for xml:space some day (ITS 2.0?)
> 
>> <its:langRule its:selector="//*" its:langMap="@myLangAttribute"/> says:
>> "@myLangAttribute" has the meaning of xml:lang.
>> Sebastian: this asserts that people use the same values as xml:lang.
> 
> OK, IMO, first case where 'mapping' is possibly making a difference: when values cannot be realistically enumerated and are the same
> as for the ITS datacat.
> 
> 
>> ************
>> proposal-09: Give up the schemaRule element
>> ************
> --> AGREE
> 
> 
> Cheers,
> -yves
> 
>