Re: Mandelieu Proposals - Comments Christian

Hi Christian, all,

Many thanks for your feedback. I would propose to put the proposals
which you and Yves did not agree upon into bugzilla. As said, I'll do
that on Friday, and include your / Yves / other comments.

Below some replies.

Lieske, Christian wrote:
> 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).

For a given data category, I want to do s.t., e.g. find nodes in an XML
document, use information about the data category in an editor, do
"mapping" etc. If we have several data categories at an <documentRule>
element, it gets rather messy to implement all such processes in a data
category separating manner. This includes the implementation of the
precedence rules we defined.
See also below a comment on proposal-08.

> 
> 
>> ************
>> 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?

having e.g. <translateRule> instead of <documentRule> means more
capabilities for validation (e.g. assuring that there is only a
@translate attribute at <translateRule>, but not at <locInfoRule>. As
for extension of ITS to more data categories, I see no differences between
- adding data category specific attributes to the old <documentRule>
elements, versus
- adding child elements with different names to <documentRule>.

> 
>> ************
>> 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. 

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

> 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.

good point. We should keep that terminology.

> Furthermore, I sth. like "dirPassThrough" rather than "dirMap" may
> capture the semantics more clearly.

mmm ... I have no objection, but would like to give our English native
speakers the last word in this terminology. I remember that "in situ",
"dislocated" etc. seemed o.k. to me, but that was a mistake ;)

> 
>> ************
>> 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.

Richard will give input on this at some point.

> 
>> ************
>> 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.

good point. I see a parallel for xml:lang, xml:space and ruby: We can
have these data categories very easily in the last call draft, by just
saying "they are defined in terms of the existing specs",.

Btw., having data category specific element names provides a clear way
to realize the "PassThrough" functionality:

<its:langRule its:selector="//*" its:langMap="@myLangAttribute"/>

<its:spaceRule its:selection="//*"
its:xmlspacePassThrough="@xyz:mySpaceAtt"/>


Cheers,

Felix

">
>> ************
>> proposal-09: Give up the schemaRule element
>> ************
> --> agree
> 
> I obfuscately once asked about the necessity to have both, documentRule
> and schemaRule.
> 
> Cheers,
> Christian
> 
> 
>