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"><b></data>
<data id="d2"></b></data>
<data id="d3"><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: [mailto:-
> open.org] On Behalf Of Yves Savourel
> Sent: 15 January 2016 22:03
> To:
> 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:]
> Sent: Friday, January 15, 2016 1:39 PM
> To: Ryan King <>; Yves Savourel
> <>;
> 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: [mailto:-
> open.org] On Behalf Of Ryan King
> Sent: Friday, January 15, 2016 10:12 AM
> To: Yves Savourel <>;
> 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: [mailto:-
> open.org] On Behalf Of Yves Savourel
> Sent: Thursday, January 14, 2016 7:13 PM
> To:
> 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'></b></data>
> <data id='d3'><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:
| www.vistatec.com | ISO 9001
| EN 15038
Expert Leadership in Global Content Solutions
