Thanks for confirmation – we will also log a bug for MS OM library on GitHub.
Patrik
From: David Filip [mailto:]
Sent: Thursday, December 17, 2015 3:01 PM
To: Patrik Mazanek <>
Cc: XLIFF Main List <>
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.
Cheers
dF
Dr. David Filip
===========
OASIS XLIFF OMOS TC Chair
OASIS XLIFF TC Secretary, Editor, Liaison Officer
Spokes Research Fellow
ADAPT Centre
KDEG, Trinity College Dublin
Mobile: +420-777-218-122
On Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek <> wrote:
HI,
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"
srcLang="en-GB" trgLang="fr-FR">
<file id="f1" original="myfile">
<unit id="1">
<segment id="id1" >
<source>Example of an sm with <sm id="2" type="term"/> term</source>
</segment>
</unit>
</file>
</xliff>
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.
Regards
Patrik Mazanek
l
Product Owner – Translation productivity
l
SDL
l
Language Technologies Division
l
(T) +49 (0)1520 9098850
l
(F) +49 711 780 4197
www.sdl.com
SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and
we further request that you advise us.
SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.
This message has been scanned for malware by Websense.
www.websense.com
Click
here to report this email as spam.
www.sdl.com
SDL PLC
confidential, all rights reserved. If you are not the intended recipient
of this mail SDL requests and requires that you delete it without acting
upon or copying any of its contents, and we further request that you
advise us.
SDL PLC is a public limited company registered in
England and Wales. Registered number: 02675207.
Registered address:
Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.
