JLIFF notes (unit and above)

Hi everyone,

A few notes I got while continue to try implementing write/read in JLIFF.

(Some are notes for objects above the unit, I know it’s not the focus for now, but I’m putting them down to not forget about them).

- It seems there is an optional directionality flag on the XLIFF <data> object. This means (if we stick with it) not be able to use a true map for originalData in JLIFF. Maybe a way around this could be to have Unicode directionality marker on the data themselves. Not sure if it’s a good idea.

- I think targetOrder is still missing from the segment properties (it should be an integer).

- The “fragment” object (<file>) seems to have a “version” property, but that should really go above (the whole document is in that version).

- The “fragment” object is missing the “original” property.

- The “skeleton” object says that the “ref” property is required, but it is only required when the skeleton has no content.
Also: The schema is missing the skeleton content, when ref is not used.

- In the element-ec, element-sc and element-ph schema definitions there is a “text” property. What is it?
I’m guessing it’s the left-over of previous versions of the schema and should be removed.

- The id and startRef fields of the end code object are the same property expressed with two different names depending if the end code is isolated or not. That may be justified in XLIFF where there are some constraints about not having two IDs with the same value, but from the object model viewpoint there is no reason to have two properties (e.g. the Okapi implementation has only a getId() on the end-code object).
I was wondering if we should not serialize it as a unique required property in JLIFF instead of two mutually exclusive ones. It would simplify things.
Also: in the JSON schema we have startRef as required, it is incorrect: it is either startRef or id that is required, and that may be difficult to express (and that’s one more argument in favor of using a unique property).

- I’m not sure serializing “isolated” is necessary: In the implementation it is may actually be counterproductive to have that information stored as a field because you need to maintain it as you modify the content, while it can be obtained dynamically when you need it (which is mostly when rendering the content in XLIFF). It would not be a problem to have it, but I just wanted to point out the fact it can be a transient field.

That’s all for now.

I’ve updated the online Lynx prototype implementation: http://okapi-lynx.appspot.com/jliff

Cheers,

-yves

xliff-omos message