Hi all, I've looked at the Statement of Use tracker (
https://wiki.oasis-open.org/xliff/XLIFF%202.0%20SOU%20Tracker ) and I'm a bit concern about it. I think the table in the wiki is a bit vague. For example: in the column "Segmentation", I assume putting a Yes there when the application is a Modifier means the application supports every single conformance items related to re-segmentation (and all associated to all agent types as well). That is very broad. I think we need a lot more granularity. For example currently Lynx offers a way to apply segmentation on top of the existing one, but does not implement joining segments. So I cannot state that it is compliant with the 13 processing requirements defined for joining segments. To try to be more specific and more formal in the statement of use ENLASO intends to make with the Okapi library, I've started to gather all conformance items in a table and tried to come up with a way to verify each one, so it is clear which one is implemented and works and which is either not implemented or not working. I've attached the very early version of that table for reference. I think it is very important that we record which constraints and PRs have been truly implemented, otherwise we are bound to have many of them left un-verified and potentially causing implementation issues. Some of those PRs are quite difficult to achieve. For example: "When a Modifier removes an <mrk> element or a pair of <sm> / <em> elements and the ref attribute is present, it MUST check whether or not the URI referenced by the ref attribute is within the same <unit> as the removed element. If it is and no other element has a reference to the referenced element, the Modifier MUST remove the referenced element." We do want to make sure they are realistic and have been truly implemented (I'm not sure the one above is implementable for example). Regards, -yves Attachment: conformance-table.xlsx Description: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet