RE: [xliff-omos] A few notes in JSON and inline content

[Yves Savourel <ysavourel@enlaso.com>]

Hi Ryan, all,

I think we are aiming at standardizing only the representation of the extracted data (in the XLIFF sense), no?
The parts that are not extracted are typically “external codes” like <h1> in your example. Those parts are in the skeleton.

So, using a more classic example (with an image instead of '[productname name="Acme Phone"]', but it's the same really):

Alert: <h1><img src="phone.png" alt="Acme Phone"] now available in stores.</h1> Get it today!

We would get 4 units:

- 1 for the text before <h1>
- 1 for the nested alt attribute
- 1 for the content of <h1>
- 1 for the text after <h1>

With the Okapi HTML filter that would be represented like this:

  <unit id="tu1">
   <segment>
    <source>Alert:</source>
   </segment>
  </unit>
  <unit id="tu3" type="okp:alt">
   <segment>
    <source>Acme Phone</source>
   </segment>
  </unit>
  <unit id="tu2" type="okp:h1">
   <originalData>
    <data id="d1">[#$dp1]</data>
   </originalData>
   <segment>
    <source><ph id="1" canCopy="no" canDelete="no" subFlows="tu3" dataRef="d1"/> now available in stores.</source>
   </segment>
  </unit>
  <unit id="tu4">
   <segment>
    <source>Get it today!</source>
   </segment>
  </unit>

So that means we have 4 separate JSON internal content items, not 1.

Obviously that would be also serializable in JSON, as JSON units.
The file would include probably an array of units.

[
{ // the first unit
   "id":"tu1",
   [ // the unit's segments
      { // the segment
         "source":{ // the source
            [ // the array of content objects
               "Alert:" // the plain text object
            ]
         }
      }
   ]
},
{ // the second unit
   "id":"tu3",
   "type":"okp:alt",
   [ // the unit's segments
      { // the segment
         "source":{ // the source
            [
               "Acme Phone"
            ]
         }
      }
   ]
}
// etc.
]

What about the "<h1>" between the two units?
My view is that it would be stored as part of the skeleton JSON representation at the file level, if you have a skeleton.

...

> How would I know, though, where to place </h1>? 
> So how about something even more explicit:

That second representation with the two tags at the same level as their content looks closer to the non-nested one: I like it better.

Cheers,
-yves