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: SOU expectations

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


Attachment: conformance-table.xlsx
Description: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

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