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,

Many thanks for your reply.

The point here is twofold: On the one hand, there is the old (SGML/XML) question about what to favor in design elements or attributes, and on the other hand, the begin-end annotation marker has an additional workflow-oriented semantics which is expressed in the statement "... They also can be split by segmentation. Because of this, a single annotation span can be represented using a pair of <sm> and <em> elements instead of a single <mrk> element." (Page 48).

It seems that there is no need to express this distinction, and the same effect for the overlap and the segmentation example could be accomplished with the following markup for which I've introduced just two new attributes (here with an "mx" namespace) with (URI-like) referential values:

<unit id="1">
      <source>Sentence A. </source>
<source><mrk id="m1" mx:annotation-span-close="#m2" type="comment" value="Comment for B and C"/>Sentence B.
<source>Sentence C.<mrk id="m2" mx:annotation-span-open="#m1"/></source>

For the actual XLIFF 2.0 specification you could use the attributes 'endRef' (begin marker) and 'startRef' (end marker), the latter being already used for the <em> element. Both would be required for the specific overlap/split case.

One further remark concerns the 'type' attribute with value 'term', which as it stands now doesn't provide any value if no reference to a glossary can be given (but see also my comment on the Glossary Module).

Cheers -- Jörg

On June 01, 2013 at 02:11 (CEST), Yves Savourel wrote:
Hi Jörg,

The annotation elements <sm> and <em> are just specialized cases of the
<mrk> element. Since they don't add any additional value to the inline
annotation markup, they could be subsumed under <mrk>. Therefore, a justification
of their existence would be most valuable.

The reason for <sm> and <em> elements to exist is the same as for <sc> and <ec> compared to <pc>: It's to allow overlapping
elements. For example when you have some metadata applied to a content across two sentences, and then the content is segmented or
marked up with some other overlapping metadata.

We went back and forth between this solution and duplicating <mrk>, and the pros/cons favored using <sm>/<em> at the end.

As for justifying those elements: there is a link in their definition to the Annotation section where, I think, it's explained there
in details. Do you think some additional text is needed in the <sm> and <em> section? Maybe another link to the section "Splitting


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