OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-omos message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Chase,


That’s correct.

And the same for <mrk>…</mrk> à <sm/>…<em/>




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





Dr. David Filip



OASIS XLIFF TC Secretary, Editor, Liaison Officer

Spokes Research Fellow

ADAPT Centre

KDEG, Trinity College Dublin



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

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.


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:



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]