Thanks Rodolfo for the comments and feedback. See our response inline.
From:
xliff@lists.oasis-open.org [mailto:
xliff@lists.oasis-open.org]
On Behalf Of Rodolfo M. Raya
Sent: Friday, November 16, 2012 1:51 AM
To:
xliff@lists.oasis-open.org Subject: RE: [xliff] 2.0 Validations Module Proposal
Hi Ryan,
All possible actions should be defined in the module. It cannot be left open to let end users create custom rule types. Every tool that supports the module should
be able of supporting all validation types.
[ryanki] We didn’t see this restriction about modules in the specification, can you point us to it? Would it make more sense if the x- naming convention were
used? In that case, any tool supporting <validations> that doesn’t have knowledge of the rule could safely ignore it.
There should be just one <validations> element in each allowed place.
[ryanki] Like <notes> and <metadata> we are advocating having a name attribute that would allow you to have more than one “grouping” at the same extension point.
A scenario for this might be that you have groups of validations where some of them you want to run during one phase of your workflow and others during another.
The elements <validation> and <matchExpression> should be combined into one (<matchExpression> can be discarded, as it does not contain any attribute and the
regular _expression_ could be the content of <validation>).
[ryanki] Point taken. We’ll make that change.
The element containing the regular _expression_ should have an "xml:space" attribute set to "preserve" by default.
[ryanki] point taken. We’ll make that change.
Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms
http://www.maxprograms.com
Original Message --------
Subject: [xliff] 2.0 Validations Module Proposal
From: Ryan King < ryanki@microsoft.com >
Date: Thu, November 15, 2012 10:01 pm
To: " xliff@lists.oasis-open.org " < xliff@lists.oasis-open.org >
In anticipation of closing down on 2.0, we have two new proposals for modules. In this mail, we are proposing the first of the two, a Validation module.
Validating localized target data is a very important part of the business of outsourcing localization, especially when the extracted source content comes from software. Typically,
there is a plethora of tools that content providers and localization suppliers use to perform a multitude of validations. There is a strong desire in the industry to bring some consistency to this space, but there are currently no accepted standards or interchange
formats that facilitate this activity. We would like to propose a Validation module that would help with standardizing this crucial activity.
The basic idea would be to define a small set of standard validation rules and standard descriptions for them that tool developers could consistently build business logic around.
How a rule is applied to a string or sub-string would be done using regular expressions. These would all be contained in a Validations module.
Here’s a draft of the Module for comment:
Validations Module
The target text of a document can be verified against various validation rules. The Validations Module should be able to store a list of pre-defined validation rules, along with a description about how to process the target text using those rules, to perform
specific verifications.
Module Specification
Module Namespace
The namespace for the Verification module is: urn:oasis:names:tc:xliff:validations:2.0
Module Elements
The elements defined in the Validations module are: <validations>, <validation>, and <matchExpression>.
Tree Structure
Legend:
1 = one + = one or more ? = zero or one
<validations> +
+---<validation> +
+---<matchExpression> 1
validations
Collection of validations to be applied by a validation engine
Contains:
- One or more <validation> elements
Parents:
<file>, <group>, <unit> and <segment>
Attributes:
- name
validation
Specifies a validation rule, and a description and regular _expression_, which define how to apply that validation rule to the target text.
Contains:
- One <matchExpression> element
Parents:
<validations>
Attribute s:
- id, rule, desc
matchExpression
A regular _expression_ used to match the target text or substring to which the validation rule is applied.
Contains:
A regular _expression_
Parents:
<validation>
Attribute s:
- none
Module Attributes
The attributes defined in the Validations module are: name, id, rule, and desc.
name
Name – The user-defined name of a named validations element.
Value description: NMTOKEN.
Default value: undefined
Used in: <validations>.
id
Identifier - A character string used to identify a <validation> element.
Value description: NMTOKEN.
Default value: undefined
The value must be unique within the <validations> element.
Used in: <validation>.
rule
Validation Rule - Indicates the rule that a validation engine should apply to the target text.
Value description: A paired value with desc. See table below.
Default value: undefined
Used in: <validation>
desc
Validation description – indicates how a specific rule should be applied to the target text.
Value description: A paired value with rule. See table below.
Default value: undefined
Used in: <validation>.
Possible values for rule and desc attributes (format and number of rules TBD) :
Rule
Description
maxLength:100
Match string can’t be longer than # of chars specified.
minLength:10
Match string can’t be shorter than # of chars specified.
noLoc
Match string shouldn’t be localized
Etc.
Etc.
Any custom rule
Any custom description
Examples in XLIFF:
Using the following segment as an example
<segment>
<source> Contact me at someCompany:
user@somecompany.com </source>
<target> Kontaktieren Sie mich unter someFirma:
user@somecompany.com </target>
</target>
maxLength:100
. Matches “Kontaktieren Sie mich unter someFirma:
user@somecompany.com “.
Match succeeds, so validation business logic checks to see if the string is less than 100 chars, that also succeeds, and the business logic then takes the appropriate action.
<val:validations>
<validation rule=”maxLength:100” desc=” Match string can’t be longer than # of chars specified.”>
<matchExpression>.</matchExpression>
</validation>
</val:validations>
noLoc
someCompany doesn’t match “someCompany” in the target text.
Validation business logic takes the appropriate action for the match failure.
<val:validations>
<validation rule=”noLoc” desc=” Match string shouldn’t be localized.”>
<matchExpression>someCompany</matchExpression>
</validation>
</val:validations>
Rules not defined in the Module can still be defined using the same mechanisms, though user agents that support the Validation Module may or may not have built-in implementation
for them. An example might be to check if the target text contains a valid email address.
validEmail
[A-Z0-9._%+-] +@[A-Z0-9.-]+.[A-Z]{2,4} matches “ user@somecompany.com ”.
Validation business logic takes appropriate action for the match success.
<val:validations>
<validation rule=”validEmail” desc=” Match string is a valid email address.”>
<matchExpression>[A-Z0-9._%+-] +@[A-Z0-9.-]+.[A-Z]{2,4}</matchExpression >
</validation>
</val:validations>
Please let us know your opinion on this proposal.
Thanks,
Microsoft Corporation
(Ryan King, Kevin O'Donnell, Uwe Stahlschmidt, Alan Michael)
--------------------------------------------------------------------- To unsubscribe, e-mail:
xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
xliff-help@lists.oasis-open.org