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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Ryan, all,

I’ve looked more closely at this, and while it’s not a very specific as what "corresponding" means, the bullet--"The inline elements enclosed by a <target> element MUST use the duplicate id values of their corresponding inline elements enclosed within the sibling <source> element if and only if those corresponding elements exist."--is a constraint and we should verify it at least to some degree.

So I've started to implement addition checks: they do not verify 'data', 'dataDir', 'dataRef', and 'dir' for the codes, and 'value' and 'ref' for the markers. I think a tool could change those with good reason: they are not necessarily the same between source and target. But at least check is done for 'type', 'subType', 'can*', etc. which are really more like immutable metadata instead of content.

The change is in the Okapi repository, but not yet in the built snapshot or the online checker. 

Cheers,
-ys


---------------------------------------------
From: Ryan King [mailto:ryanki@microsoft.com] 
Sent: Friday, June 19, 2015 6:42 AM
To: Yves Savourel; 'Estreen, Fredrik'; xliff@lists.oasis-open.org
Subject: RE: [QUAR] RE: [xliff] RE: Inline attributes and canCopy

Thanks, Yves, I think you see now why we've been having trouble with this constraint. Your reply points out many of the difficulties my developer and I have been struggling to understand how to validate. It also makes it clear to me that we probably can't validate this constraint in our OM adequately without additional PR/constraints. I think our behavior in the OM will need to mirror Lynx.