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



All

 

I came up with two approaches and I’m sure there could be more. They do not suffer from many of the complexities expressed in my start of this thread (thank goodness). Apologies if implementation of the standard is not your thing, I find that sometimes it teases out issues.

 

The first uses an object hierarchy: JliffBase <- JliffOfSubUnits, JliffOfUnits, JliffOfFiles, etc.

 

The second uses generics: Jliff<ISubUnit>, Jliff<File>, Jliff<IUnit>, etc. This does mean that this implementation has a single property called “content” rather than “units”, “files”, “groups”, etc.

 

In both cases the de-serialization has to do a bit of work reflecting what concrete types the interfaces are holding.

 

I have to re-work some of my utility methods but they were probably of a bad design in the first place in hindsight.

 

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: Wednesday 26 July 2017 13:40
To: Phil Ritchie <phil.ritchie@vistatec.com>
Cc: Yves Savourel <ysavourel@enlaso.com>; Chase Tingley <chase@spartansoftwareinc.com>; David Filip <david.filip@adaptcentre.ie>; XLIFF OMOS TC <xliff-omos@lists.oasis-open.org>
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

Facebook

LinkedIn

Twitter

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