RE: [xliff] <sm/> and

Hi Ryan, apologies, I haven't answered yet.
We discussed this in the last TC and Fredrik took the action item to answer with a spec reference.
In short, the spec says that annotations are either mrk or pairs of sm / em.
Fredrik will provide the reference.
isolated doesn't exist, by design, on sm / em, so really there is no mechanism to make orphaned annotations, and hence no need for an explicit Constraint prohibiting them.

Finally, I want to clarify - and I said the same in the last meeting (not sure if the minutes are out yet) - that it is impossible to change XLIFF 2.0.
The OASIS process has produced XLIFF 2.0, which is now immutable, "set in stone" if you wish. This is true for any OASIS Standard and in fact for any numbered draft of any OASIS standard work product, starting with cs01. Anyways, OASIS Standard is the last state of the OASIS state machine; editorial fixes can be pushed through Errata. But to amend anything you need to "deprecate" the old standard with producing a new standard that replaces and supersedes the older version..
We agreed not to spend time and effort on producing Errata.
Instead, where core seems unclear or open to more than 1 interpretation, we are free (and have agreed) to add more clarity when restating the core in 2.1.
IMHO, we don't need an explicit Constraint saying that orphaned sm / em are invalid.
But at the same time, if the TC agrees that having such an explicit Constraint brings more clarity, I think there is no issue with having it in 2.1. It doesn't constitute a material or logical change compared to what 2.0 core states, IMHO and AFAIK.
Personally, I believe that it would be enough to add a Note and invalid test suite files with orphaned sm and em. BTW, we are free to maintain / amend the 2.0 test suite, as the test suite is not a formal part of the multi-part work product; merely an implementation aid that the TC promised to provide..
I hope this helps
Cheers
dF

On Feb 23, 2016 02:15, "Ryan King" <ryanki@microsoft.com> wrote:

Hi David, apologies if you already answered and I missed it. Can you clarify my question below?

Thanks,

Ryan

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Tuesday, February 2, 2016 11:40 AM
To: 'xliff@lists.oasis-open.org' <xliff@lists.oasis-open.org>
Subject: [xliff] <sm/> and 

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.

Thanks,
Ryan

From: David Filip [mailto:david.filip@adaptcentre.ie]
Sent: Thursday, December 17, 2015 3:01 PM
To: Patrik Mazanek <pmazanek@sdl.com>
Cc: XLIFF Main List <xliff@lists.oasis-open.org>
Subject: Re: [xliff] <sm/> and 

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/>/ 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 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 <pmazanek@sdl.com> wrote:

HI,

I wanted to ask about <sm/> and tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and elements. What it doesn’t say if you can have situation where only <sm/> or 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

xliff message