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: A few notes in JSON and inline content


Hi all,

We have to start somewhere, so maybe a good place is a simple inline content. It's one of the most tricky parts to serialize in a
common way because the internal representation of such content is likely to be different in the various implementations depending on
how the overall document is stored (e.g. DOM, DB, memory, etc.) and also on what the implementation goals are (e.g. do matching, be
the back-end of an editor, etc.).

A possible effective representation would be the simplest. It may not fit exactly the underlying object of all implementations, but
it should be relatively easy to generate and parse by all.

Such content is simply an array of objects. So for example, if we have this object (here in XLIFF so everyone can relate to it):

<originalData>
 <data id='d1'>&lf;b></data>
 <data id='d2'>&lt;/b></data>
 <data id='d3'>&lt;br></data>
</originalData>
...
<source>Text in <pc id='1' dataRefStart='d1' dataRefEnd='d2'>bold</pc> format.<ph id='2' dataRef='d3'/></source>

The JSON representation could be something like this:

[  "Text in ",
   {
      "kind":0,
      "id":"1",
      "data":"<b>"
   },
   "bold",
   {
      "kind":1,
      "id":"1",
      "data":"<\/b>"
   },
   " format.",
   {
      "kind":2,
      "id":"2",
      "data":"<br>"
   }
]  

The array has 6 objects: 3 strings, which correspond to the spans of plain text, and 3 objects corresponding to the inline tags. The
objects would have a relatively identical structure. The "kind" field (trying to keep "type" for the XLIFF-type) would indicate if
the object is an opening code (0), and closing code (1), a standalone code (3), an opening marker (4) or a closing marker (5).

We would have also some rules:

- The fields that have values equals to the default value MAY be omitted in the JSON string.
- The fields within the objects would have no prescribed order.
- The fields common to both the opening and closing codes (e.g. id, type, etc.) would be represented once only: in the opening code.
If there is no opening code (i.e. there is an isolated closing code) the fields would be represented in the closing code.

This is just one possible representation.
I'm sure others have better ideas and suggestions.

Cheers,
-yves





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