Hi David, Patrik logged a bug for this against the MS XLIFF 2.0 OM on GitHub. Can you verify when and if the PR will be added to the 2.0 spec? We do
not want to fix it as a bug in the OM validator unless it is reflective of what is actually in the spec.
From: David Filip [mailto:email@example.com]
Sent: Thursday, December 17, 2015 3:01 PM
To: Patrik Mazanek <firstname.lastname@example.org>
Cc: XLIFF Main List <email@example.com>
Subject: Re: [xliff] <sm/> and <em/>
Thanks, Patrik, there was a discussion on this back in summer 2014.
While orphaned <sc/> and <ec/> are possible and allowed because XLIFF Agents are not in control of the native markup in the original and target format.
Now, XLIFF Agents are always in control of annotations. The <mrk> and <sm/>/<em/> behave largely analogically to <pc> and <sc/>/<ec/> except that they don't have attributes and
Constraints and PRs to handle orphaned cases.
It follows implicitly that orphaned <sm/> or <em/> are not allowed in a scope of any <unit>.
I guess the Okapi and MSFT OM don't catch this, as there is no explicit Constraint or PR to prohibit that.
I would suggest that we add such PR, as it wouldn't be really chanhing the spec materially, just adding explicit wording to what otherwise follows implicitly.
Dr. David Filip
OASIS XLIFF OMOS TC Chair
OASIS XLIFF TC Secretary, Editor, Liaison Officer
Spokes Research Fellow
KDEG, Trinity College Dublin
On Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek <firstname.lastname@example.org> wrote:
I wanted to ask about <sm/> and <em/> tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and <em> elements. What it doesn’t
say if you can have situation where only <sm/> or <em/> is present, e.g.:
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" version="2.0" xml:space="preserve"
<file id="f1" original="myfile">
<segment id="id1" >
<source>Example of an sm with <sm id="2" type="term"/> term</source>
It seems both Okapi validator and MS XLIFF OM validate the example above as valid file. If this is indeed correct I believe we should enhance the specification and make sure this
bit is explained a bit better.
Product Owner – Translation productivity
Language Technologies Division
(T) +49 (0)1520 9098850
(F) +49 711 780 4197