[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [QUAR] RE: [xliff] RE: Inline attributes and canCopy
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:email@example.com] Sent: Friday, June 19, 2015 6:42 AM To: Yves Savourel; 'Estreen, Fredrik'; firstname.lastname@example.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.