RE: [xliff] 2.0 Validations Module Proposal

[Ryan King <ryanki@microsoft.com>]

Thanks Yves, see inline.

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Friday, November 30, 2012 8:29 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] 2.0 Validations Module Proposal

Hi Ryan, all,

A few questions:

> desc - optional unspecified text

I assume this attribute contain the description of what the given valuation does.

[ryanki] Correct. 

> rule - required unspecified text

I assume this attribute hold some kind of name for the given rule, is that right?

[ryanki] Correct again.

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

If it's an XPath expression I assume it applies to the node(s) of the source/target/both, but what is the return type to use for the evaluation? (BOOLEAN?, DOM_OBJECT_MODEL?, NODE?, NODESET? NUMBER?, STRING?)
[ryanki] Whatever the query expression defines.

XQuery has even more implementation questions: how does the data source is related to the entry? Is the full XQuery set available (one can query other files, etc.)?

At this point we might as well go full throttle and make that content a JavaScript script. But as you can guess the least restrictive the content of matchExpression is, the least useable it is outside of that specific XLIFF document.

[ryanki] This is the same reason why we aren't proposing XQuery. However, if the TC members are OK with more than just the pattern match functionality that RegEx and XPath give us, i.e. being able to specify complex query and transformation functions akin to XSLT, then we can certainly add that option to a ballot.

A few more notes, in general:

I don't want to sound negative but maybe this module needs a lot more thoughts and test implementations before it's truly ready for prime-time. For example, what do the tools makers of applications like XBench or QADistiller, etc. think of this? After all they support XLIFF and QA functions and are widely used. They would be one of the the types of implementers.

[ryanki] Are there members in the TC from these companies, or do folks have contacts in these companies that they can share?

If the TC wants a stable Committee Draft published in January, maybe we should focus on the core and possibly tweak the few modules that have been worked on since several months. As long as we have a good process in place to integrate new modules there is no really a need to rush. After all such validation module (or other modules) could be extensions for a while.

[BTW: I'm still not enthusiastic about how it looks like we will integrate new modules: incrementing the version seems to be a complex process: that will require OASIS members (not just TC members) to vote on it, something that is not easy to get done at all.]

I have to say that I tend to agree with Rodolfo on the flurry of last minute additions: it's probably not a very healthy way to move to a committee draft.

cheers,
-yves



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org