RE: [xliff-omos] XLIFF OM diagrams

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

Thanks a lot for the initial diagrams Patrik.

Here are a few notes after a quick glance:

--- I don't think the OM should have things that are only mandated because XLIFF is XML. A good example of that is the CodeProtection object. In the OM there is no reason to treat XML-forbidden characters in a special way: we are not in XML. And on serialization, we would write a <cp> for XLIFF, but that's not needed for JSON.

--- I know the diagrams are still incomplete, but one aspect that would be of high interest is how overlapping and isolated start and end codes are represented. I don't think they can be with represented with Placeholder or TagPair. But it's probably just not there yet.

--- I'm not sure how to read the diagram, but I assume the ElementContainer is part of the PairTag, so it is recursive, right?

--- Related to that: I would tend to avoid recursive content if it can be modeled more simply. A model with 3 types of objects for the codes (Placeholder, StartCode and EndCode) would allow a linear view of the content. This doesn't prevent the API to provide methods to get spans of content corresponding to a TagPair.

We actually went through the "pc or no pc" discussion when defining XLF2 inline codes, some of you can recall: At some point we thought having only <ph>, <sc/> and <ec/> enough. We added <pc> to make things more XML-friendly. That argument is not really longer valid here.

--- I would tend to simplify things by keeping the original data of a code with that code rather than keep a separated list: It simplifies the OM operations in general (e.g. adding, deleting). The reason it's a separated list in XLIFF is just because we didn't want to have mixed original-data/text in the TEXT nodes of <source>/<target>.


Cheers,
-yves