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,

Yes, both the segment/ignorable and the group/unit will need the same class identification mechanism.
We discussed it a bit at the last TC call.
If I recall correctly the consensus was to maybe have a key/value pair object named 'class' with a standard value for the various cases in all those cases.

-ys

PS: I also got your other email: I'll try to gather thoughts/things and answer tomorrow.


-----Original Message-----
From: Ryan King [mailto:ryanki@microsoft.com] 
Sent: Tuesday, May 31, 2016 5:50 PM
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, all,

First off an apology for coming back to this so late. My other job keeps me very busy :)

Yes, Yves, thanks for catching the typo. Also, you are correct that I fell back into the duplicated object name trap once again (that makes twice for me...one more time and I'm out of the TC, I think.)

So, I know think that a merger of your example and my first example is in order:

{
        "id": "u1",
        "myNS:xattr": "extValue",
        "containers": [{
                "container": "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]"
                }]
        }, {
                "container": "ignorable",
                "source": [".  "]
        }]
}

Here I chose to use the label "containers" and "container" which is close to the terminology used in the MS XLIFF 2.0 OM class for segment and ignorable with values of "segment" or "ignorable" to be more explicit.

It occurs to me that we will need to do something similar for units and groups as well, and so maybe "containers" and "container" needs to be more explicit as well. In the MS XLIFF 2.0 OM we call the classes: ContainerResource (segment, ignorable) and TranslationContainer (group, unit)...the inconsistency with the placement of "Container" is just an unfortunate oversight.

Let me know what you think. Thanks!

Ryan  

-----Original Message-----
From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Tuesday, April 12, 2016 9:05 AM
To: xliff-omos@lists.oasis-open.org
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



---------------------------------------------------------------------
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 




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