I should add, the 0.9.3 schema only supports sm/em, not a full mrk-equivalent, so that part is already good. (I've added an additional commit to the PR to add "startRef" to the ec, and fix my broken example where the ec was using "id" to refer to the corresponding sc.) 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@spartansoftwarei nc.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.o rg > 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/x liff-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/x liff-omos-jliff/blob/master/JL IFF-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:xlif f: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/cz y4y2emlg4liqcq ): 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.x qy?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/app s/org/workgroup/portal/my_work groups.php