Apologies if this is the wrong place for such feedback. I contemplated posting a GitHub ticket but this won out.

I have started a very basic implementation of the example json files in C#. The library I'm using to serialize and de-serialize the json gets very confused when trying to de-serialize the Segments array and the Segment boolean of the Unit. I only code part-time these days so it could be my engineering limitations or limits of the library but perhaps the property which indicates whether a Segment or Ignorable follows could be named unambiguously. I'm hoping to use Segment(s) as the Unit property name in my code so it's more intuitive and has a fluent feel.

Phil


From Chase (after some discussion over email):

I think your code example could be streamlined even more, because there's no need (I don't think?) for the SubUnit class to exist. It could just be an interface which is implemented by Segment and Ignorable. So your example would look like this:

var model = new File(
        new List<Unit>()
        {
        new Unit(
            new List<SubUnit>()
            {
            new Segment(
                new List<IElement>() {new TextElement("New fluent source.")},
                new List<IElement>() {new TextElement("New fluent target.")}
                )
            })
        });

SubUnit is something that doesn't exist in XLIFF, it was introduced in the OM to try to abstract out the commonalities between Segment and Ignorable. The working JLIFF schema is based on the OM (at least, as it was several weeks ago), but I'm not sure we've gotten this part quite right:

    "subunit": {
      "type": "object",
      "properties": {
        "segment": { "type": "boolean" },
        "canResegment": { "type": "boolean" },
        "state": { "type": "string", "enum": [ "initial", "translated", "reviewed", "final" ] },
        "source": { "$ref": "#/definitions/elements" },
        "target": { "$ref": "#/definitions/elements" }
      },
      "additionalProperties": false,
      "required": [ "segment", "source" ]
    },

This allows for nonsensical things like "canResegment" on an ignorable section, for example. We may need to break things back out more explicitly between Segment and Ignorable types, and in that case maybe there is a better JLIFF serialization. I need to dig deeper into how the JSON schema document recommends handling polymorphism, however.

ExampleFeedback (last edited 2017-01-26 20:42:43 by ctingley)