Mandelieu Proposals

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

Received on Wednesday, 1 March 2006 18:36:45 UTC