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

[Yves Savourel <ysavourel@enlaso.com>]

> while strictly speaking JSON does not **forbid** uniqueness of the names,

Sorry I obviously meant: "...does not **force** uniqueness of the names".

-ys

-----Original Message-----
From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Friday, January 15, 2016 3:03 PM
To: xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] A few notes in JSON and inline content

Hi Ryan, all,

I don't think it would be a good idea to use a notation where the names of the objects correspond to their type, like in your
example.

We would have duplicates (like "plainText" twice in your example) and it is likely to cause trouble.

The JSON specification does not say anything explicit about uniqueness of the names. But RFC 7159 (The JSON Data Interchange Format:
http://tools.ietf.org/html/rfc7159#section-4) says "The names within an object SHOULD be unique". And usually one is better off
treating a SHOULD like a MUST unless there are very good reason to do otherwise.

The main example of issue with duplicated names is that many implementations of JSON reader use some kind of Map, Hash, or
Dictionary classes that do not support duplication of keys.

See also the discussion here: http://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object. The
consensus seems to be that, while strictly speaking JSON does not forbid uniqueness of the names, it is a really good idea to keep
these names unique for all kinds of very valid reasons.

Cheers,
-yves


-----Original Message-----
From: Ryan King [mailto:ryanki@microsoft.com]
Sent: Friday, January 15, 2016 1:39 PM
To: Ryan King <ryanki@microsoft.com>; Yves Savourel <ysavourel@enlaso.com>; xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] A few notes in JSON and inline content

Sorry, I should also ask the question of why original codes need a type, or kind, as you indicate below. Couldn't they just be
distinct objects in the model? Maybe there is a nuance I am missing, though.

For example:
standaloneCode
spanningCode
spanningCodeStart
spanningCodeEnd
etc.

Thanks,
Ryan

-----Original Message-----
From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Friday, January 15, 2016 10:12 AM
To: Yves Savourel <ysavourel@enlaso.com>; xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] A few notes in JSON and inline content

Hi Yves, 

Thanks for getting the ball rolling. I absolutely agree with you that we should just start defining the JSON representation.
Starting at inline and working out is good, as well. Once we agree on inline representation, the rest is easier. So I'm all for this
approach. I do see the representation of your sample a bit differently, however. In the MS OM, the sample would be represented as an
array of four objects:  PlainText, SpanningCode, PlainText, StandaloneCode - just using those object names as an examples, you could
serialize it to something like this:

{

   "plainText": "Text in",

   "spanningCode": {

      "id": "1",

      "codeStart": "<b>",

      "codeEnd": "</b>",

      "innerText": "bold"

   },

   "plainText": "format.",

   "standaloneCode": {

      "id": "2",

      "code": "<br>"

   }

}

Thanks,
Ryan

-----Original Message-----
From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Thursday, January 14, 2016 7:13 PM
To: xliff-omos@lists.oasis-open.org
Subject: [xliff-omos] 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




---------------------------------------------------------------------
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/apps/org/workgroup/portal/my_workgroups.php 


---------------------------------------------------------------------
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/apps/org/workgroup/portal/my_workgroups.php 



---------------------------------------------------------------------
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/apps/org/workgroup/portal/my_workgroups.php