The representation of pc/mrk content

[Yves Savourel <ysavourel@enlaso.com>]

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