Re: [xliff-omos] The representation of pc/mrk content

On Mon, Mar 13, 2017 at 12:20 PM, Chase Tingley <chase@spartansoftwareinc.com> wrote:

Pull request to implement the proposed changes for <pc>:

https://github.com/oasis-tcs/xliff-omos-jliff/pull/2

On Mon, Mar 13, 2017 at 12:15 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi Chase,

That’s correct.
And the same for <mrk>…</mrk> à <sm/>…<em/>

-ys

From: Chase Tingley [mailto:chase@spartansoftwareinc.com]
Sent: Monday, March 13, 2017 1:11 PM
To: David Filip <david.filip@adaptcentre.ie>
Cc: Yves Savourel <ysavourel@enlaso.com>; XLIFF OMOS TC <xliff-omos@lists.oasis-open.org>
Subject: Re: [xliff-omos] The representation of pc/mrk content

Hi Yves,

Thanks for spotting this.

If I'm reading the rest of your message & David's followup correctly, the OM position is that <pc> is an XML-ism and we will just flatten the nesting into a series of sc/ec objects.

So your XLIFF example:

<source>Hello <pc id='1'>one <pc id='2'>and</pc> all</pc>! </source>

Might be encoded in JLIFF as something close to:

"source": [
{ "kind": "sc", id="1" },
{ "text": "one " },
{ "kind": "sc", id="2" },
{ "text": "and" },
{ "kind": "ec", id="2" },
{ "text": " all" },
{ "kind": "ec", id="1" },
{ "text": "! " }
]

(Note: I'm using the current "text" serialization, which doesn't include a "kind" field. Whether it needs one is a separate discussion.)

On Thu, Mar 9, 2017 at 4:44 AM, David Filip <david.filip@adaptcentre.ie> wrote:
Good point, Yves,

we indeed agreed to get rid of the recursive elements in the OM, as also reflected on the current diagram

https://github.com/oasis-tcs/xliff-omos-om/blob/master/model/Model_LIFF_Class_Diagram.PNG

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 Mon, Mar 6, 2017 at 10:46 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi all,

Looking at https://github.com/oasis-tcs/xliff-omos-jliff/blob/master/JLIFF-schema-draft/jliff-schema-0.9.3.json#L219 I've noticed
that the representation of element-pc (and element-mrk) is just a "text" string.

This does handle the many cases where any other inline tag could be in the content. For example this basic file:

<xliff xmlns='urn:oasis:names:tc:xliff:document:2.0' version='2.0'
srcLang='en' trgLang='fr'>
<file id='1'>
<unit id='1'>
<segment>
<source>Hello <pc id='1'>one <pc id='2'>and</pc> all</pc>! </source>
<target>Bonjour <pc id='1'>tous <pc id='2'>et</pc> chacuns</pc> ! </target>
</segment>
</unit>
</file>
</xliff>

Obviously a solution would be to use

"text": { "$ref": "#/definitions/elements" }

But this is ringing alarm bells for me: I don't think we want recursive objects in the content.

I think we did discuss the pc vs sc/ec case (see http://markmail.org/message/czy4y2emlg4liqcq): in the object model is it not one of
the goals to get rid of the constraints brought up by using XML? In such context only the representation for sc/ec, ph and sm/em are
needed (see for example the diagram http://markmail.org/download.xqy?id=vcqwzpp7q5t7ywzh&number=2 ).

Technically, one could even have simple objects for those inline boundary markers and a reference to a separate object with all its
properties instead of the duplication.

Cheers,
-yves

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xliff-omos message