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

Hi Felix, all,

>> The key is probably that the rules are just a way 
>> to define the default behavior, not necessarily to implement it.
> How about when saying this: the default rules are like default 
> styling in browsers? That is, without CSS, a "p" has a different 
> styling than "h1" etc.
> This would also fit for precedence: for a given node,
> 1) if there is local markup apply that else
> 2) if there is a global rule match apply that
> 3) if there is an inherited value apply that
> 4) if there is a default (with additional info*) apply that The above
> 1-4 is what we actually have , after resolving issue-70 with 
> Frederiks proposal at
> we then just could say: "(with additional info*)" for HTML means: 
> a table with one column the HTML markup, and the other column the data category values assumed.

It sounds good. with one caveat: implementing those defaults in a way they get overridden by inherited values may be quite challenging. I know it would for us as we use global rules for this. For example, a default to make translatable //meta/@content[@name='keywords'] would be very challenging as it would have to be applied away from the code where we can access all attributes of a given element.

Hard-coded defaults are ok for small isolated cases, but in the scale of the whole HTML tag sets it's a bit more daunting without the help of the global rules.

>From the maintenance view point too: such default would very likely be hard-coded, so when/if there is a need for adding or changing some with new versions of HTML it'll be more difficult that relying on a rules file.

I do see the advantage of it (avoiding the non-intuitive things the author would have to override if we were using a default set of global rules). But I'm worried about feasibility.


Received on Monday, 25 February 2013 14:02:43 UTC