A couple years back I was working on a project where we were using an ad-hoc JSON-based serialization to send translation data to a browser, and we actually did something very similar to what Phil is proposing -- wrap text as an object with a dummy type field. The thinking was that it would simplify the implementation. I've never tried it the other way (ie, the way it's currently proposed), so maybe I should do some comparing about whether it makes it a lot harder to work with.
On Mon, Feb 27, 2017 at 12:32 PM, Phil Ritchie <> wrote:
All
Apologies for my various contradictions with myself. I have a bad habit of making statements, walking away from my code and then thinking of a way to move forward.
It appears that I can override how my various subclasses write themselves to the serializer. Doing this does let me write out per the example in GitHub. It makes
deserialization slightly more work.
Phil
Phil Ritchie
Chief Technology Officer | Vistatec
Vistatec House, 700 South Circular Road,
Kilmainham, Dublin 8, Ireland.
Tel: +353 1 416 8000 | Direct: +353 1 416 8024
Email:
www.vistatec.com | ISO 9001 | ISO 13485 | EN 15038
Think Global
From: [mailto:]
On Behalf Of Phil Ritchie
Sent: 27 February 2017 15:23
To:
Subject: [xliff-omos] jliff-example1-0.9.3.json
I’ve played a bit more with my implementation and I’m not sure that jliff-example1-0.9.3.json can be achieved with a strongly typed language. Even with interfaces I cannot do:
…
“source”: [
{ “id”: “c1”, “kind”: “ph” },
“AAA”,
{ “id”: “c1”, “kind”: “ph” }
]
The closest would probably be:
“source”: [
{ “id”: “c1”, “kind”: “ph” },
{ “text”: “AAA” },
{ “id”: “c1”, “kind”: “ph” }
]
Phil
Phil Ritchie
Chief Technology Officer
|
Vistatec
Vistatec House, 700 South Circular Road,
Kilmainham, Dublin 8, Ireland.
Tel:
+353 1 416 8000
|
Direct:
+353 1 416 8024
Email:
www.vistatec.com
|
ISO 9001
|
ISO 13485
|
EN 15038
Think Global
