Re: [xliff-comment] csprd01-17: Structure and Structural Elements: <sm> <em> justification

[Jörg Schütz <joerg@bioloom.de>]

Hi Yves,

I very much tend to follow and agree with your argumentation. However, 
what is needed to strictly separate the two models, including the 
semantics of the markup elements and their associated application 
scenario, is a tight specification, i.e. a minimum of flexibility to 
ensure that the markups are appropriately used. Only with such a 
restriction you can foster the interoperability between tools when 
employing XLIFF 2.0 -- otherwise you will even get the solution that I 
used in my example, which is possible with the currently given extension 
possibilities.

Therefore, the described flexibility is a major disadvantage of the 
<mrk>, <sm>/<em> solution.

Would you and the TC mind if I would propose some possible restrictions?

Thanks and cheers -- Jörg

On June 04, 2013 at 19:00 (CEST), Yves Savourel wrote:
> Hi Jörg,
>
> > It would be great if you could share with me some of the pros
> > and cons that triggered the decision. This might also find its
> > way to the specification so that adopters and implementers
> > have a convincing rationale and appropriate use case(s) for
> > employing XLIFF 2.
>
> As I mentioned before, one example is that having distinct elements for the two models allow to have different sets of attributes and therefore easier validation.
>
> Another reason is the confusion that would brink using <mrk> sometimes empty and linked to another <mrk>, or sometime not empty and linked to no other <mrk>.
> Using three elements allows to have well-define content model and no risk of confusion or error.
>
> Another is that one would need to add create a new ID value for the closing <mrk/> so the opening one could refer to it. With <sm>/<em> a single ID value is enough.
>
> Using <sm>/<em>: <sm id='m1'/>...<em startRef='m1'/>
> Reusing <mrk>: <mrk id='m1' endRef='m1end'>...<mrk id='m1end' startRef='m1'/>
>
> Overall, we didn't see any true major advantages to re-use <mrk>.
> But we may have miss something: do you see a major advantage in using only <mrk>?
>
> Cheers,
> -yves