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,

Thanks for your prompt reply. 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.

Cheers -- Jörg

On June 03, 2013 at 00:55 (CEST), Yves Savourel wrote:
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



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