OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Subject: RE: [xliff] RE: Inline attributes and canCopy

Title: [xliff] RE: Inline attributes and canCopy

Hi Yves, all,


Thanks for sharing your implementation! We’ll take a look from our side and let you know by the end of the week.




From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Saturday, June 20, 2015 10:20 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] RE: Inline attributes and canCopy


Hi Ryan, all,

> Thanks Yves, when you have something working in Lynx, can you share

> the full implementation with me and we'll look at what we can do to

> at least have parity.

I've implemented a verification that tries to detect when two source/target codes with the same ID are not "corresponding". It’s just my best solution so far, but I’m obviously open to adjustments. I have not yet made a formal release with the change: It would be nice to get the feedback from other implementers and TC members.

Such two codes are seen as corresponding if:

- Both are either spanning (<pc>/<sc><ec>) or both standalone (<ph>)

And if they have, at least, the following properties identical:

- type

- canOverlap

- canDelete

- canRemove

- canReorder

- subFlows/subFlowStart/subFlowEnd

- canCopy

- copyOf

- disp/dispStart/dispEnd

- equiv/equivStart/equivEnd

They may have different values for all the other properties: the rational to not include the others (like data, dir, subType, etc.) is that they might be changed when they are in the target.

For the annotations: I check for identical values on:

- type

- translate

You can see the source code here:


Note that the code performs the verification on the parsed elements, so, for example, there is no distinction between the attributes disp, dispStart and dispEnd: In the object model it's just the disp property of that tag object.

You can play with the new behavior in the online validator: http://okapi-lynx.appspot.com/validation

(The issue Nesho found with <cp hex='7FFFFFFF'/> is also fixed)

There are a few test files (bad_NotCorrespondingCode*.xlf) here:


But we should also add valid test files.



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