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] JLIFF files, fragment, groups, units, subunits



I worry about these issues:

1. Interoperability with XLIFF - e.g. XLIFF expects a top-level structure, what processing steps are needed when only “subunits” are provided?

2. Model inconsistencies - e.g. “subunits” at the top-level strips the required “id” from “files” and “units”, what are the semantics implications?

3. Practical use issues - e.g. more complex code and semantics to consume JLIFF.

With respect to #2, consider the following example:

{
    "jliff": “1.1",
    "srcLang": "en",
    "trgLang": "fr",
    "files": [
        {
            "id": "fl",
            "units": [
                {
                    "id": "u1",
                    },
                    "subunits": [

Which has the required “id” property on fragment (array element of “files”), and required “id” property on “unit” (array element of “units”). Permitting “subunits” as a root level property effectively strips the required “id” from fragment and unit since this no longer represents a full fragment:

{
    "jliff": “1.1",
    "srcLang": "en",
    "trgLang": "fr",
     "subunits": [

The question is whether the two representations given above are considered semantically identical or not, or semantically close. If they are semantically identical then the “id” properties must be made optional in the full fragment representation, since the second representation omits them. If they are not semantically identical, then the semantics will need to be defined very precisely to avoid an “id” omission loophole, to put it that way.

- Robert


  Dr. Robert van Engelen, CEO/CTO Genivia Inc.
  voice: (850) 270 6179 ext 104
  fax: (850) 270 6179
  mobile: (850) 264 2676
  engelen@genivia.com

On Jul 26, 2017, at 8:02 AM, Phil Ritchie <phil.ritchie@vistatec.com> wrote:


All
 
I’ve been looking at this a little this morning and the ability to wrap the choice of ‘files’, ‘fragment’, ‘groups’, ‘units’ and ‘subunits’ introduces a lot of complexity into code both during serialization/deserialization and also utility methods such as something which would GetAllSegments().
 
From what I can see the anonymous wrapper object (named ‘jliff’ in my library) would need a ‘content’ or ‘body’ property which stores instances of an interface which ‘files’, ‘units’, ‘subunits’, etc. would conform to. This is fine but I think then each of these possible contents would need a ‘type’ property so that my serialization library can figure out what concrete type to instantiate during deserialization.
 
I’ll play with it a little more to see if I can refine it a bit.
 
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: phil.ritchie@vistatec.com
www.vistatec.com | ISO 9001 | ISO 13485 | ISO 17100 | ISO 27001
Vistatec
Think Global
FacebookLinkedInTwitterGoogle Plus
Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland.
The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s). 
​The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden. 
If you have received this message in error please notify the sender immediately.

From: Robert van Engelen [mailto:engelen@genivia.com] 
Sent: Tuesday 25 July 2017 19:40
To: Phil Ritchie <phil.ritchie@vistatec.com>; Yves Savourel <ysavourel@enlaso.com>; Chase Tingley <chase@spartansoftwareinc.com>; David Filip <david.filip@adaptcentre.ie>
Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org>
Subject: JLIFF files, fragment, groups, units, subunits
 
 
Hi,
 
The JLIFF schema 0.9.4 is updated on GitHub.
 
Added are the `srcDir` and `trgDir` properties to the JSON JLIFF “wrapper” object, each with `ltr`, `rtl`, or `auto` enumerated string values.
 
I’ve restructured the JLIFF object schema by providing a choice of `files`, `fragment`, `groups`, `units`, and `subunits` properties.
 
I’ve tested the changes with schema validators and examples. These (unofficial) tests passed.
 
See the modified `jliff` object type in the schema somewhere defined at the top.
 
- Robert



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