RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Yves,

This is brilliant! I will update my Okapi XLIFF Library with the modules.xml helper today and put some mileage on it (for my non-US colleagues, I'm using the term "mileage" to mean extra cycles of testing).

I think if this method is acceptable by the TC we should include modules.xml among the official schemas for download, state it as an official validation aid, and add a normative section in the spec on its use. We don't necessarily have to specify Lynx as the supported validation helper (though I'm not against it). We could simply define the generic process.

- Bryan 
________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com]
Sent: Saturday, December 07, 2013 12:44 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation

Hi everyone,

Here is a summary of the things I've done to try to resolve our validation issue:

- I've taken the latest schemas from SVN
- removed all references to the modules from the core
- made each module schema as independent as possible
- replaced all ##any by ##other and skip by lax

This with just running XSD validation with the independent schemas give us a good coverage of what can be checked by XSD. The
missing parts are:
a) detecting that attributes that are incorrect or not allowed in each attribute-extension point.
b) verifying which modules elements are allowed in each element-extension point.

To fix that I created a small XML document that lists all XLIFF elements where extensions or modules are allowed, and for each of
those, listed the allowed modules attributes and/or elements. See the attached modules.xml file for details.
Lynx simply checks that information when it reaches one of the extension point.

So it looks like that validation should be working now: we catch fs:badAttr="value" as well as fs:fs="badValue".

Depending on the type of error you'll get the exception sometimes from the schemas validation (run first), and other times from
Lynx' processing validation.
This should also make things relatively easy to maintain as most of the time only modules.xml needs to be updated when something
changes.

I have also started to synchronize the validation with the latest specification changes.

I haven't updated any schema on SVN, nor updated the location of the extension points (e.g. before or after <unit>/<group>).

I think at some point I'll make a Web page and/or Web service to run the validation online.
For now, the latest version is here: http://okapi.opentag.com/snapshots/okapi-xliffLib_all-platforms_0.21-SNAPSHOT.zip
And there is a Web start version here: http://okapi.opentag.com/webstart/lynx/lynx.jnlp

Cheers,
-yves