OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi Jörg,

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

No, please do.
-yves



-----Original Message-----
From: Jörg Schütz [mailto:joerg@bioloom.de] 
Sent: Wednesday, June 5, 2013 11:53 PM
To: xliff-comment@lists.oasis-open.org
Subject: Re: [xliff-comment] csprd01-17: Structure and Structural Elements: <sm> <em> justification

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
>

--
This publicly archived list offers a means to provide input to the OASIS XML Localisation Interchange File Format (XLIFF) TC.

In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.

Subscribe: xliff-comment-subscribe@lists.oasis-open.org
Unsubscribe: xliff-comment-unsubscribe@lists.oasis-open.org
List help: xliff-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/xliff-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff
Join OASIS: http://www.oasis-open.org/join/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]