RE: [xliff] 2.0 Validations Module Proposal

[Kevin O'Donnell <kevinod@microsoft.com>]

There has been a good, detailed discussion around this validations module proposal. We are grateful for the input - certainly, lots of worthwhile points to consider. Considering the revised proposal outlined by Ryan last week, can we proceed to a approve/reject ballot in the near future? That was the recommendation in the previous TC call.

The work to decide the specific implementation and detail can still continue, but we'd like to achieve certainty around the feature's inclusion in XLIFF 2.0. Regardless of the mechanics of the validation feature, I expect it will need careful consideration and compromise among implementers - something we can realistically only expect after we publish XLIFF 2.0. This will allow for improvement/extension of the feature in future revisions.

Thanks,
Kevin.

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Saturday, December 01, 2012 6:40 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] 2.0 Validations Module Proposal

hi Ryan, all,

>>> <matchExpression>
>>
>> I may have missed some previous description and I apologize for this, 
>> but if that element hold an 'expression' (XPath, regex, etc.) I'm not 
>> quite sure how to apply it (from an implementer viewpoint). Does it 
>> applies to the source content and if no match is found it's an error, 
>> or to the target content? or both?
>
> [ryanki] Unless we have a bunch of pre-defined standard rules and 
> descriptions, so that a tool implementer would know the business logic 
> to take depending on what the match returns, the most we can assume is 
> that the match's success or failure can be acted upon in some way. 
> Success or failure of the match can be a good start for a first implementation, at least.

But how exactly the expression should be used?
I think we have to be very specific otherwise you can end up with applications that use the same metadata very differently, even if they use the same regex engone.

for example:

a) I can apply the regex to the target and if I don't get a match it constitutes a failure of the validation.
b) I can combine the text of both source and target and apply the regex, and no match constitute a failure.

but depending on a or b, the regex needs to be very different.

also: how inline codes fit into this? do we pass the raw XML to the regex? (then how can tools not working natively with XLIFF use this?) Should the regex support extra metacharacters that match code (e.g. \k means 'any code' and the tool knows how to match\k to its own representation of the code), etc.

How source and target are linked (if they are)? for example: Many QA tools use pairs of regex to run validation rules (See attached screen shot), one for the source the other for the target. They often add some extra keyword or logic to allow linking the two fields.

I'm not trying to sink your proposal, far from it. I just think that to be more than an private extension it probably need a lot more processing descriptions, and input from implementers. And maybe it will end up being very simple and consider out of scope a lot of what QA tools do.



>> ...do the tools makers of applications like XBench or QADistiller, etc.
>> think of this?
>
> [ryanki] Are there members in the TC from these companies, or do folks 
> have contacts in these companies that they can share?

ENLASO is doing QA tools and that's why I'm providing all that feedback.
SDL and Lionbridge have also QA/validation components: fredrik provided some feedback.
For XBench: Josep is in the xliff-comments list 9 https://lists.oasis-open.org/archives/xliff-comment/)
For QA Distiller: Thomas may be in the xliff-comments list too.


-ys