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: RE: [xliff-omos] A few notes in JSON and inline content


Hi Ryan, all,

Thanks for posting the example.
I have a few comments on it:


First I think there are typos in the JSON rendering, which make the "ignorable" a child of the "segment".

My guess is that it's a typo, but I'd like to be sure :)

It seems there are some array that should be object and vice-versa; and also "segment" and "ignorable" should be object rather than array. For example a problem is that the last ']' (after "ignorable" closes the '[' of "segment", etc.

I think what was meant to be was this (easier to see with all the indentations):

{
    "id": "u1",
    "myNS:xattr": "extValue",
	"segment":
	{
		"state": "translated",
		"canResegment": false,
		"source":
		[
			{
				"id": "c1",
				"standaloneCode": "[C1\/]"
			},
			" aaa ",
			{
				"id": "c2",
				"spanningCodeStart": "[C2]"
			},
			"text",
			{
				"id": "c2",
				"spanningCodeEnd": "[\/C2]"
			}
		],
		"target":
		[
			{
				"id": "c1",
				"standaloneCode": "[C1\/]"
			},
			" AAA ",
			{
				"id": "c2",
				"spanningCodeStart": "[C2]"
			},
			"TEXT",
			{
				"id": "c2",
				"spanningCodeEnd": "[\/C2]"
			}
		]
	},
	"ignorable":
	{
		"source": 
		[
			".  "
		]
	}
}

The structure may be more visible when seen in a dynamic display.
For instance in https://jsonformatter.curiousconcept.com you can copy the JSON code and get the corresponding dynamic tree.


Now, assuming the tree above is what was intended, I'm not sure it would work well because of the possible key duplication:

If we have a unit with multiple segments, like this:

 <unit id="u1">
  <segment>
   <source>First sentence.</source>
  </segment>
  <ignorable>
   <source> </source>
  </ignorable>
  <segment>
   <source>Second sentence.</source>
  </segment>
 </unit>

We would get a tree where there are two "segment" keys:

{
    "id": "u1",
	"segment":
	{
	    "source":
        [
            "First sentence."
        ]
    },
    "ignorable":
    {
        "source": 
        [
            " "
        ]
    },
    "segment":
    {
        "source":
        [
            "Second sentence."
        ]
    }
}

It's technically not invalid JSON (the spec say keys SHOULD be unique not MUST be unique). But it is universally seen as a problem by the parsers.

In my humble opinion I think we should avoid using a name/value pair for representing an object when more than one object of that type may exists in a given container.

Cheers,
-yves




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