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 <> 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 <> 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
