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


Attachment: screenshot.png
Description: PNG image

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