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 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.

-----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>?


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