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

["Yves Savourel" <yves@opentag.com>]

Hi Jörg,

Thanks for the additional information.

One of the reasons why the TC selected to use different elements rather than to re-use the same element with additional attributes is because re-using the same element for two very different content model seemed to have more cons than pros.

For example, having distinct elements for the "spanning model" vs the "anchors model" allowed to have different sets of attributes, making validation easier.

We did look at both models for <sc>/<ec>/<pc> as well and found also that there were more pros than cons to use 3 elements rather than one. We also wanted to be consistent for annotations, hence: <sm>/<em>/<mrk>.

We even looked at the possibility to not have <mrk> or <pc> but only <sm>/<em> and <sc>/<ec>, but that didn't go through.

I'll let the term question be handled with the glossary comment.

Cheers,
-yves



-----Original Message-----
From: Jörg Schütz [mailto:joerg@bioloom.de] 
Sent: Sunday, June 2, 2013 9:25 AM
To: xliff-comment@lists.oasis-open.org
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">
    <segment>
       <source>Sentence A. </source>
    </segment>
    <segment>
       <source><mrk id="m1" mx:annotation-span-close="#m2" 
type="comment" value="Comment for B and C"/>Sentence B.
	  </source>
    </segment>
    <segment>
       <source>Sentence C.<mrk id="m2" 
mx:annotation-span-open="#m1"/></source>
    </segment>
</unit>

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 Annotations"?
>
> 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/