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.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php