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: Interoperability

Hi all,

Like Rodolfo I tend to think applications are block boxes we cannot know anything about.
There is nothing more we can do for verifying interoperability than look at XLIFF documents.

But, like Andrew I hope we can go one step further than a simple output validation by providing processing expectations that can help the implementer to manipulate the XLIFF data with some rules.

We should not tell the tool what operations it should do, but we can tell the tool how to do some operations.
For example with <match> (i.e. <alt-trans> in 1.2) we can be very specific about the values the attributes have, and about having a processing expectation that says, for instance, that if you merge two segments their respective <match> elements must be discarded, or their associated matching score be downgraded (or whatever we decide).

But we cannot tell what an application will do with those elements, for example we cannot assume that a workbench application will use the <match> target content to fill the unit's <target> (even if they are perfect matches), etc.

In other words, we need to treat the application as a black box. I would just try to verify the interoperability through two means: a) validate the output document using the schema and likely a specialized tool. And b) compare the input and output to verify (as much as possible) that the changes follow the processing expectations. 

I think b) would be hard to automate and that it's probably not doable for every processing expectation. But it can certainly be done for some. And it certainly can be verified manually by users.


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