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

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

Hi Yves,

Sorry for being late with my answer. I was on travel which also included 
spreading the word of XLIFF and ITS in the BPM and BI communities.

Well, here are some suggestions for improving the annotation description 
plus some further ideas and questions for clarifying and/or streamlining 
the attributes.

******
Description proposal:

An annotation is a markup element <mrk> (mark) that associates a 
particular part of the content with metadata information. Annotations 
may be created by the tool that generates the initial XLIFF document, or 
by any other tool or user agent after this generation process. For 
example, after a first tool has created the XLIFF document, a second 
tool annotates the source content with terminological information.
Since annotations can overlap spanning inline codes or other 
annotations, a single annotation span should be marked up by using a 
pair of <sm> (start mark) and <em> (end mark) elements instead of the 
single <mrk> element. How this change of the annotation might be 
accomplished is shown in the following example of a re-segmentation of 
the source content.

SEGMENTATION EXAMPLE (see specifications)

It is strongly recommended to use this mechanism instead of introducing 
custom attributes to accomplish a similar behavior with a series of 
<mrk> elements.

******

Attributes with additonal clarifications and questions:

id -- annotation identifier that is always mandatory
translate -- sort of process(ing) instruction being either yes or no 
(overwrites the value set in an enclosing <segment> and/or <unit> 
element; any other restrictions?)
type -- generic (default; added value and/or restrictions for 
value/ref?), term, comment, or user defined string (custom case)
value -- text representing the "definition of a term" (term case), or 
the text of a comment if present, otherwise the ref attribute must be 
used (comment case), or user defined (custom case)
ref -- URI pointing to a resource with term information (term case), or 
a <note> element (comment case; any restriction?, e.g. <note> must 
appear in <segment> or <unit>), or user defined (custom case; how to 
point to a <note> element? Any restrictions?)

******

I hope that these suggestions will improve the readability of the 
specification, and make things a bit clearer for those who want to 
deploy XLIFF.

Cheers -- Jörg


On June 06, 2013 at 13:05 (CEST), Yves Savourel wrote:
> 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