Re: ACTION-447: Make a batch transformation of the test suite to xliff

Thanks a lot for your replies, Yves and Fredrik. You nearly convinced 
me. Also, we should probably make sure that the outcome of
with the rule set.

Why I wrote "nearly": in the below you write about HTML5 (and its 
successor, I assume) - but what about XHTML and the other HTML flavours? 
I am having here again the Linguaserve workflow in mind. Do we then 
require (or suggest via SHOULD) Linguaserve to process against the 
default rule set in the XHTML workflow?

Also, a detail: the rules would have no influence on precedence and 
overriding, etc. right? - they are kind of assuming that each HTML 
element has an "invisible linked or external rules file" - which has the 
lowest precedence compared to other rules, but a higher one than 
inheritance? E.g.

<span its-within-text="no"><span> ...</span></span>

the inner span would be overriden by the

  <its:withinTextRule withinText="yes"
   selector="//h:abbr | //h:acronym | //h:br | //h:cite | //h:code | //h:dfn
   | //h:kbd | //h:q | //h:samp | //h:span | //h:strong | //h:var | //h:b | //h:em
   | //h:big | //h:hr | //h:i | //h:small | //h:sub | //h:sup | //h:tt | //h:del
   | //h:ins | //h:bdo | //h:img | //h:a | //h:font | //h:center | //h:s | //h:strike
   | //h:u | //h:isindex" />

Taken from



Am 22.02.13 03:13, schrieb Yves Savourel:
> All good points Felix,
> see inline...
>> OK ... but in the example below Fredrik said that Okapi specifies
>> keywords to be translatable as a default. Can we expect that this is a default
>> for all HTML filters?
> That's what we have in our default currently (after all keywords are translatable...)
> But it should be whatever the WG decide should be the default rules.
>> And related: Fredrik wrote "One of the default global html5 rules (in Okapi)
>> specifies <meta name="keywords"…’s content to be translatable".
>> Is this really a global rule (which somebody who knows where it is stored
>> could modify), or a default, non ITS rules based processing?
> In our case it's a real rule.
> (See we have actually 2 sets: the 'strict' one is used for running the test cases)
> But does it matter? The bottom line is that the behavior of a processor that says "I support the HTML5 default rules" is the same, whether it is realized by internal rules or hard-coded statements.
>> Also, would the link be to a rules file in the spec or in the wiki
>> (so that more easily it could be updated)? For the need to do that see e.g.
>> here: HTML5.1 will have new elements, e.g.
>> and we state we are covering HTML5 or its sucessor with ITS2.
> Mmm... I guess it should be in the BP which can be updated.
>> Also ... in the example below two data categories are processed by
>> Okapi: Translate and Domain. What do we expect from a tool that
>> only implements domain, with regards to the defaults of data
>> categories not being implemented?
> They just ignore the rules they don't implement, just like for any other rules file.
>> And asking again (I may have missed the answer, in that case sorry
>> for that): why was this not needed for ITS 1.0? See
>> ("what I still don't get" part).
> My (current) 2 cents:
> We never dealt with HTML in the ITS 1.0 specification.
> The reference to the XHTML rules is just an 'example', like for DITA, TEI, DocBook, etc.
> In 2.0 an ITS processor that support HTML5 is currently only having a very limited expected behavior (id, lang, etc.) but there is nothing in the specification saying for example that title attributes are translatable.
> Sure we can say each filter has to complement the 'raw' behavior with its own set of pre-defined rules. But such rules affect how local markup will be processed. So we would end up with a single HTML5 document marked up with ITS info that will have two different outputs with two different tools as each tools would set its own defaults.
> By providing at least a default set of rules to complement the 'raw' behavior, we provide the authors with at least a base for their local markup.
> cheers,
> -yves

Received on Friday, 22 February 2013 12:09:13 UTC