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

[Phil Ritchie <Phil.Ritchie@vistatec.com>]

All

I came across the same issue as Yves with Ryan's notation, namely duplicate keys. The Newtonsoft Json library used by most C# developers strips off the first plaintext field.

From playing with both, nested inline tags are also difficult to handle in Ryan's notation.

I did find Ryan's more intuitive to read though.

We have quite a lot of content that contains custom placeholders with translateable attributes. In XLIFF, right or wrong, we encode as:

	<originalData>
		<data id="d1">&lt;b></data>
		<data id="d2">&lt;/b></data>
		<data id="d3">&lt;br/></data>
		<data id="d4">[productname name="</data>
		<data id="d5">"]</data>
	</originalData>
	<!--
	<h1>[productname name="Acme Phone"] now available in stores</h1>
-->
	<source>
		<pc id="1" dataRefStart="d1" dataRefEnd="d2">
			<pc id="2" dataRefStart="d4" dataRefEnd="d5">Acme Phone</pc> now available in stores
		</pc>
	</source>

Making a hybrid of Yves and Ryan's notation I get:

[
    {
        "id": "1",
        "codeStart": "<h1>",
        "codeEnd": "</h1>",
        "innerContent": {
            "id": "2",
            "codeStart": "[productname=\"",
            "codeEnd": "\"]",
            "innerContent": "Acme Phone"
        }
    },
    " now available in stores"
]

Phil

> -----Original Message-----
> From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-
> open.org] On Behalf Of Yves Savourel
> Sent: 15 January 2016 22:03
> 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

Phil Ritchie | Chief Technology Officer | VistaTEC

VistaTEC House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland.

Tel: +353 1 416 8000

Email: Phil.Ritchie@vistatec.com | www.vistatec.com | ISO 9001 | EN 15038

    

Expert Leadership in Global Content Solutions