OASIS XML Localisation Interchange File Format (XLIFF) TC

More on this attribute validation issue: If I use <xs:anyAttribute namespace="##any" processContents="strict"/> the bad attribute fs:badAttr is correctly seen as a bad attribute. If I use 'lax" no error is reported. I don't understand why: the definition for "lax" is suppose to be "The XML processor attempts to obtain the schema for the required namespaces and validate any attribute from those namespaces; however, if the schema cannot be obtained, no errors will occur." But this is behaving like if the validators cannot find the schema if the name of the attribute is incorrect. BTW: I've also checked that the problem is not coming from my validator: I get the same behavior in Oxygen when providing the two same schemas with xsi:schemaLocation. I'm baffled. Any pointer would be helpful. -yves

Yves, This seems to contradict the XSD specification. With anyAttribute set to "lax", a bad attribute should throw an error when a schema for the containing namespace has been found. But as you note, it doesn't. The common interpretation of "lax" is that it throws no error when the schema for the namespace is not found, nor when the schema is found but a definition of the attribute is not part of that schema. It seems to be commonly accepted (and commonly implemented, as you've seen). If anyone knows where that detail is hidden in the W3C spec for XSD, I'd like to know. Tom
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Wednesday, December 04, 2013 02:49 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation More on this attribute validation issue: If I use <xs:anyAttribute namespace="##any" processContents="strict"/> the bad attribute fs:badAttr is correctly seen as a bad attribute. If I use 'lax" no error is reported. I don't understand why: the definition for "lax" is suppose to be "The XML processor attempts to obtain the schema for the required namespaces and validate any attribute from those namespaces; however, if the schema cannot be obtained, no errors will occur." But this is behaving like if the validators cannot find the schema if the name of the attribute is incorrect. BTW: I've also checked that the problem is not coming from my validator: I get the same behavior in Oxygen when providing the two same schemas with xsi:schemaLocation. I'm baffled. Any pointer would be helpful. -yves

I see... So would the solution to define dummy element using the attributes? I guess I'll try.
Original Message----- From: Tom Comerford [ mailto:tom@supratext.com ] Sent: Wednesday, December 4, 2013 1:32 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Yves, This seems to contradict the XSD specification. With anyAttribute set to "lax", a bad attribute should throw an error when a schema for the containing namespace has been found. But as you note, it doesn't. The common interpretation of "lax" is that it throws no error when the schema for the namespace is not found, nor when the schema is found but a definition of the attribute is not part of that schema. It seems to be commonly accepted (and commonly implemented, as you've seen). If anyone knows where that detail is hidden in the W3C spec for XSD, I'd like to know. Tom
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Wednesday, December 04, 2013 02:49 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation More on this attribute validation issue: If I use <xs:anyAttribute namespace="##any" processContents="strict"/> the bad attribute fs:badAttr is correctly seen as a bad attribute. If I use 'lax" no error is reported. I don't understand why: the definition for "lax" is suppose to be "The XML processor attempts to obtain the schema for the required namespaces and validate any attribute from those namespaces; however, if the schema cannot be obtained, no errors will occur." But this is behaving like if the validators cannot find the schema if the name of the attribute is incorrect. BTW: I've also checked that the problem is not coming from my validator: I get the same behavior in Oxygen when providing the two same schemas with xsi:schemaLocation. I'm baffled. Any pointer would be helpful. -yves

> I see... So would the solution be to define dummy > element using the attributes? I misunderstood. You were obviously talking about the bad attribute not being defined (not the good one being used in an element in FS schema). Yes, this makes not much sense for 'lax' to behave like 'skip' if it doesn't find the attribute in the schema. I'll keep looking. -ys
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Wednesday, December 4, 2013 1:42 PM To: 'Tom Comerford'; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation I see... So would the solution to define dummy element using the attributes? I guess I'll try.

Hi Tom, all, I've brought the issue to Felix Sasaki a W3C resource quite familiar with XML and schema. He pointed out that the XSD specification seems to indicate this behavior. [[ I think the issue is that the "lax" option is not defined on a "per schema" basis but on a "per declaration" basis. See from http://www.w3.org/TR/xmlschema-1/#Wildcard_details "lax: If the item has a uniquely determined declaration available, it must be .valid. with respect to that definition, that is, .validate. if you can, don't worry if you can't." That is, since the validator does not find a declaration for "fs:wrong" in the schema, it just skips validation. I assume what you want is: "if in a target namespace no declaration is given, give me an error". The only way I can see this happen is NVDL. ]] In other words (if I get it right): lax validates only things for which it finds a valid definition. Which, in my opinion, is a bit dumb: If it's marked up as part of a namespace but no definition for it exist in that namespace the logical thing to do should be to throw an error. But I guess that's not how lax is defined. So I think that path is pretty much close. I've tried the testing with NVDL and it works fine. The problem for NVDL is that it can't directly test for locations: we can check that fs:fs="bad" and fs:wrong="value" are both bad, but we can't test hwre they are allowed to appear. For that we would need an extra part: a set of Schematron rules. It's doable, but probably not in a short timespan. And there is still all the constraints and PRs we simply can't test with schema or even Schematron. So at this point, it seems we could move forward with removing the modules references from the core, make sure each schema is independent as much as possible. Validating a file against those will catch already many issues, and we can code the rest along with the non-schema validation. Cheers, -yves
Original Message----- From: Tom Comerford [ mailto:tom@supratext.com ] Sent: Wednesday, December 4, 2013 1:32 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Yves, This seems to contradict the XSD specification. With anyAttribute set to "lax", a bad attribute should throw an error when a schema for the containing namespace has been found. But as you note, it doesn't. The common interpretation of "lax" is that it throws no error when the schema for the namespace is not found, nor when the schema is found but a definition of the attribute is not part of that schema. It seems to be commonly accepted (and commonly implemented, as you've seen). If anyone knows where that detail is hidden in the W3C spec for XSD, I'd like to know. Tom
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Wednesday, December 04, 2013 02:49 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation More on this attribute validation issue: If I use <xs:anyAttribute namespace="##any" processContents="strict"/> the bad attribute fs:badAttr is correctly seen as a bad attribute. If I use 'lax" no error is reported. I don't understand why: the definition for "lax" is suppose to be "The XML processor attempts to obtain the schema for the required namespaces and validate any attribute from those namespaces; however, if the schema cannot be obtained, no errors will occur." But this is behaving like if the validators cannot find the schema if the name of the attribute is incorrect. BTW: I've also checked that the problem is not coming from my validator: I get the same behavior in Oxygen when providing the two same schemas with xsi:schemaLocation. I'm baffled. Any pointer would be helpful. -yves

Thanks, Yves. I haven't had much reason to deal with the particular use case, but it's good to know the authoritative answer. It seems some less-formal sources of information out there aren't so reliable. Imagine that.
Original Message----- From: Yves Savourel [ mailto:ysavourel@enlaso.com ] Sent: Thursday, December 05, 2013 02:25 PM To: 'Tom Comerford'; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Hi Tom, all, I've brought the issue to Felix Sasaki a W3C resource quite familiar with XML and schema. He pointed out that the XSD specification seems to indicate this behavior. [[ I think the issue is that the "lax" option is not defined on a "per schema" basis but on a "per declaration" basis. See from http://www.w3.org/TR/xmlschema-1/#Wildcard_details "lax: If the item has a uniquely determined declaration available, it must be .valid. with respect to that definition, that is, .validate. if you can, don't worry if you can't." That is, since the validator does not find a declaration for "fs:wrong" in the schema, it just skips validation. I assume what you want is: "if in a target namespace no declaration is given, give me an error". The only way I can see this happen is NVDL. ]] In other words (if I get it right): lax validates only things for which it finds a valid definition. Which, in my opinion, is a bit dumb: If it's marked up as part of a namespace but no definition for it exist in that namespace the logical thing to do should be to throw an error. But I guess that's not how lax is defined. So I think that path is pretty much close. I've tried the testing with NVDL and it works fine. The problem for NVDL is that it can't directly test for locations: we can check that fs:fs="bad" and fs:wrong="value" are both bad, but we can't test hwre they are allowed to appear. For that we would need an extra part: a set of Schematron rules. It's doable, but probably not in a short timespan. And there is still all the constraints and PRs we simply can't test with schema or even Schematron. So at this point, it seems we could move forward with removing the modules references from the core, make sure each schema is independent as much as possible. Validating a file against those will catch already many issues, and we can code the rest along with the non-schema validation. Cheers, -yves
Original Message----- From: Tom Comerford [ mailto:tom@supratext.com ] Sent: Wednesday, December 4, 2013 1:32 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Yves, This seems to contradict the XSD specification. With anyAttribute set to "lax", a bad attribute should throw an error when a schema for the containing namespace has been found. But as you note, it doesn't. The common interpretation of "lax" is that it throws no error when the schema for the namespace is not found, nor when the schema is found but a definition of the attribute is not part of that schema. It seems to be commonly accepted (and commonly implemented, as you've seen). If anyone knows where that detail is hidden in the W3C spec for XSD, I'd like to know. Tom
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Wednesday, December 04, 2013 02:49 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation More on this attribute validation issue: If I use <xs:anyAttribute namespace="##any" processContents="strict"/> the bad attribute fs:badAttr is correctly seen as a bad attribute. If I use 'lax" no error is reported. I don't understand why: the definition for "lax" is suppose to be "The XML processor attempts to obtain the schema for the required namespaces and validate any attribute from those namespaces; however, if the schema cannot be obtained, no errors will occur." But this is behaving like if the validators cannot find the schema if the name of the attribute is incorrect. BTW: I've also checked that the problem is not coming from my validator: I get the same behavior in Oxygen when providing the two same schemas with xsi:schemaLocation. I'm baffled. Any pointer would be helpful. -yves

Hi everyone, I don't think we decided where to place the re-grouped modules/extension. Here is the current status: File: - modules are between optional <skeleton>/<notes> and <unit>/<group> - extensions are after the <unit>/<group> -> should we put the re-grouped modules/extensions before or after the core elements? Group: - all after the core elements Unit: - all after the core elements Thanks, -yves
Original Message----- From: Tom Comerford [ mailto:tom@supratext.com ] Sent: Thursday, December 5, 2013 1:34 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Thanks, Yves. I haven't had much reason to deal with the particular use case, but it's good to know the authoritative answer. It seems some less-formal sources of information out there aren't so reliable. Imagine that.
Original Message----- From: Yves Savourel [ mailto:ysavourel@enlaso.com ] Sent: Thursday, December 05, 2013 02:25 PM To: 'Tom Comerford'; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Hi Tom, all, I've brought the issue to Felix Sasaki a W3C resource quite familiar with XML and schema. He pointed out that the XSD specification seems to indicate this behavior. [[ I think the issue is that the "lax" option is not defined on a "per schema" basis but on a "per declaration" basis. See from http://www.w3.org/TR/xmlschema-1/#Wildcard_details "lax: If the item has a uniquely determined declaration available, it must be .valid. with respect to that definition, that is, .validate. if you can, don't worry if you can't." That is, since the validator does not find a declaration for "fs:wrong" in the schema, it just skips validation. I assume what you want is: "if in a target namespace no declaration is given, give me an error". The only way I can see this happen is NVDL. ]] In other words (if I get it right): lax validates only things for which it finds a valid definition. Which, in my opinion, is a bit dumb: If it's marked up as part of a namespace but no definition for it exist in that namespace the logical thing to do should be to throw an error. But I guess that's not how lax is defined. So I think that path is pretty much close. I've tried the testing with NVDL and it works fine. The problem for NVDL is that it can't directly test for locations: we can check that fs:fs="bad" and fs:wrong="value" are both bad, but we can't test hwre they are allowed to appear. For that we would need an extra part: a set of Schematron rules. It's doable, but probably not in a short timespan. And there is still all the constraints and PRs we simply can't test with schema or even Schematron. So at this point, it seems we could move forward with removing the modules references from the core, make sure each schema is independent as much as possible. Validating a file against those will catch already many issues, and we can code the rest along with the non-schema validation. Cheers, -yves
Original Message----- From: Tom Comerford [ mailto:tom@supratext.com ] Sent: Wednesday, December 4, 2013 1:32 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Yves, This seems to contradict the XSD specification. With anyAttribute set to "lax", a bad attribute should throw an error when a schema for the containing namespace has been found. But as you note, it doesn't. The common interpretation of "lax" is that it throws no error when the schema for the namespace is not found, nor when the schema is found but a definition of the attribute is not part of that schema. It seems to be commonly accepted (and commonly implemented, as you've seen). If anyone knows where that detail is hidden in the W3C spec for XSD, I'd like to know. Tom
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Wednesday, December 04, 2013 02:49 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation More on this attribute validation issue: If I use <xs:anyAttribute namespace="##any" processContents="strict"/> the bad attribute fs:badAttr is correctly seen as a bad attribute. If I use 'lax" no error is reported. I don't understand why: the definition for "lax" is suppose to be "The XML processor attempts to obtain the schema for the required namespaces and validate any attribute from those namespaces; however, if the schema cannot be obtained, no errors will occur." But this is behaving like if the validators cannot find the schema if the name of the attribute is incorrect. BTW: I've also checked that the problem is not coming from my validator: I get the same behavior in Oxygen when providing the two same schemas with xsi:schemaLocation. I'm baffled. Any pointer would be helpful. -yves

Hi Yves, all, I think the modules and extensions should go before the <unit> and <group> elements on all levels. It would be consistent and it would allow stream processing of <unit>s regardless of how the grouping around them looks. If they should go before skeleton / notes I don't have any opinion on. Regards, Fredrik Estreen >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: den 6 december 2013 13:47 > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - validation > > Hi everyone, > > I don't think we decided where to place the re-grouped modules/extension. > > Here is the current status: > > File: > - modules are between optional <skeleton>/<notes> and <unit>/<group> > - extensions are after the <unit>/<group> > -> should we put the re-grouped modules/extensions before or after the > core elements? > > Group: > - all after the core elements > > Unit: > - all after the core elements > > Thanks, > -yves > > >
Original Message----- > From: Tom Comerford [ mailto:tom@supratext.com ] > Sent: Thursday, December 5, 2013 1:34 PM > To: Yves Savourel; xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - validation > > Thanks, Yves. I haven't had much reason to deal with the particular use case, > but it's good to know the authoritative answer. It seems some less-formal > sources of information out there aren't so reliable. Imagine that. > > >
Original Message----- > From: Yves Savourel [ mailto:ysavourel@enlaso.com ] > Sent: Thursday, December 05, 2013 02:25 PM > To: 'Tom Comerford'; xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - validation > > Hi Tom, all, > > I've brought the issue to Felix Sasaki a W3C resource quite familiar with XML > and schema. > He pointed out that the XSD specification seems to indicate this behavior. > > [[ > I think the issue is that the "lax" option is not defined on a "per schema" > basis but on a "per declaration" basis. See from > http://www.w3.org/TR/xmlschema-1/#Wildcard_details > > "lax: If the item has a uniquely determined declaration available, it must be > .valid. with respect to that definition, that is, .validate. > if you can, don't worry if you can't." > > That is, since the validator does not find a declaration for "fs:wrong" in the > schema, it just skips validation. > > I assume what you want is: "if in a target namespace no declaration is given, > give me an error". The only way I can see this happen is NVDL. > ]] > > In other words (if I get it right): lax validates only things for which it finds a > valid definition. Which, in my opinion, is a bit > dumb: If it's marked up as part of a namespace but no definition for it exist in > that namespace the logical thing to do should be to throw an error. > But I guess that's not how lax is defined. > > So I think that path is pretty much close. > > I've tried the testing with NVDL and it works fine. The problem for NVDL is > that it can't directly test for locations: we can check that fs:fs="bad" and > fs:wrong="value" are both bad, but we can't test hwre they are allowed to > appear. For that we would need an extra part: a set of Schematron rules. > It's doable, but probably not in a short timespan. And there is still all the > constraints and PRs we simply can't test with schema or even Schematron. > > So at this point, it seems we could move forward with removing the modules > references from the core, make sure each schema is independent as much > as possible. Validating a file against those will catch already many issues, and > we can code the rest along with the non-schema validation. > > Cheers, > -yves > > >
Original Message----- > From: Tom Comerford [ mailto:tom@supratext.com ] > Sent: Wednesday, December 4, 2013 1:32 PM > To: Yves Savourel; xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - validation > > Yves, > > This seems to contradict the XSD specification. With anyAttribute set to "lax", > a bad attribute should throw an error when a schema for the containing > namespace has been found. But as you note, it doesn't. > > The common interpretation of "lax" is that it throws no error when the > schema for the namespace is not found, nor when the schema is found but a > definition of the attribute is not part of that schema. It seems to be > commonly accepted (and commonly implemented, as you've seen). If > anyone knows where that detail is hidden in the W3C spec for XSD, I'd like to > know. > > Tom > > >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: Wednesday, December 04, 2013 02:49 PM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - validation > > More on this attribute validation issue: > > If I use <xs:anyAttribute namespace="##any" processContents="strict"/> > the bad attribute fs:badAttr is correctly seen as a bad attribute. If I use 'lax" > no error is reported. > > I don't understand why: the definition for "lax" is suppose to be "The XML > processor attempts to obtain the schema for the required namespaces and > validate any attribute from those namespaces; however, if the schema > cannot be obtained, no errors will occur." > > But this is behaving like if the validators cannot find the schema if the name > of the attribute is incorrect. > > BTW: I've also checked that the problem is not coming from my validator: I > get the same behavior in Oxygen when providing the two same schemas > with xsi:schemaLocation. > > I'm baffled. Any pointer would be helpful. > -yves > > >

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 <?xml version="1.0"?> <modules> <!-- Definition of where in the core, modules elements and attributes are allowed. --> <location name="file"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <element name="{urn:oasis:names:tc:xliff:metadata:2.0}metadata"/> <element name="{urn:oasis:names:tc:xliff:resourceData:2.0}resourceData" zeroOrMore="yes"/> <element name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}profiles"/> <element name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}data"/> <element name="{urn:oasis:names:tc:xliff:validation:2.0}validation"/> </location> <location name="group"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}storageRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfo"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfoRef"/> <element name="{urn:oasis:names:tc:xliff:metadata:2.0}metadata"/> <element name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}data"/> <element name="{urn:oasis:names:tc:xliff:validation:2.0}validation"/> </location> <location name="unit"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}storageRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfo"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfoRef"/> <element name="{urn:oasis:names:tc:xliff:matches:2.0}matches"/> <element name="{urn:oasis:names:tc:xliff:glossary:2.0}glossary"/> <element name="{urn:oasis:names:tc:xliff:metadata:2.0}metadata"/> <element name="{urn:oasis:names:tc:xliff:resourceData:2.0}resourceData" zeroOrMore="yes"/> <element name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}data"/> <element name="{urn:oasis:names:tc:xliff:validation:2.0}validation"/> </location> <location name="note"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> </location> <location name="ph"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}equivStorage"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfo"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfoRef"/> </location> <location name="pc"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}equivStorage"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}storageRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfo"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfoRef"/> </location> <location name="sc"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}equivStorage"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}storageRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfo"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfoRef"/> </location> <location name="ec"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}equivStorage"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfo"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeInfoRef"/> </location> <location name="mrk"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}equivStorage"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}storageRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeRestriction"/> </location> <location name="sm"> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}fs"/> <attribute name="{urn:oasis:names:tc:xliff:fs:2.0}subFs"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}equivStorage"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}storageRestriction"/> <attribute name="{urn:oasis:names:tc:xliff:sizerestriction:2.0}sizeRestriction"/> </location> </modules>

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

Hi Bryan, > 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. Not too sure about making any of this normative. In my view, the only normative place where to specify at what locations the modules' attributes and elements are allowed in the core should be the specification of each module. Having modules.xml as a non-normative help would be fine, but I'm not sure we should normalize its usage. Because if we do and need to change, we'll go back to square one on having dependencies when updating modules. -ys
Original Message----- From: Schnabel, Bryan S [ mailto:bryan.s.schnabel@tektronix.com ] Sent: Sunday, December 8, 2013 10:03 AM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation 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

> Having modules.xml as a non-normative help would be fine, > but I'm not sure we should normalize its usage. Because > if we do and need to change, we'll go back to square one > on having dependencies when updating modules. ... Or maybe I misunderstood what you said, which is entirely possible :) -ys

Yves, I have a bad habit of trying to communicate an idea I am excited about during a period that I do not have adequate time to communicate clearly. In this case my brain wanted to say we should add a section on its use to the non-normative schema and catalog section. But my hurried fingers typed that we should add a normative section on its use (implied: to the schema and catalog section). So, let me be more careful and try again. If the modules.xml method is acceptable to the TC we should include it among the official schemas for download, state it as an official validation aid, and add it to the non-normative Schemas and Catalog Listings section (xliff-core-v2.0-wd03.html#coreListings) as A.4 Module Compliance Aid. I am not married to calling it " Module Compliance Aid." But nonetheless, I think it has a place in the spec. Hope this makes a bit more sense. Thanks, Bryan
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Sunday, December 08, 2013 1:18 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Hi Bryan, > 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. Not too sure about making any of this normative. In my view, the only normative place where to specify at what locations the modules' attributes and elements are allowed in the core should be the specification of each module. Having modules.xml as a non-normative help would be fine, but I'm not sure we should normalize its usage. Because if we do and need to change, we'll go back to square one on having dependencies when updating modules. -ys
Original Message----- From: Schnabel, Bryan S [ mailto:bryan.s.schnabel@tektronix.com ] Sent: Sunday, December 8, 2013 10:03 AM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi Bryan, > Hope this makes a bit more sense. I think it does. -ys
Original Message----- From: Schnabel, Bryan S [ mailto:bryan.s.schnabel@tektronix.com ] Sent: Thursday, December 12, 2013 12:12 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Yves, I have a bad habit of trying to communicate an idea I am excited about during a period that I do not have adequate time to communicate clearly. In this case my brain wanted to say we should add a section on its use to the non-normative schema and catalog section. But my hurried fingers typed that we should add a normative section on its use (implied: to the schema and catalog section). So, let me be more careful and try again. If the modules.xml method is acceptable to the TC we should include it among the official schemas for download, state it as an official validation aid, and add it to the non-normative Schemas and Catalog Listings section (xliff-core-v2.0-wd03.html#coreListings) as A.4 Module Compliance Aid. I am not married to calling it " Module Compliance Aid." But nonetheless, I think it has a place in the spec. Hope this makes a bit more sense. Thanks, Bryan
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Sunday, December 08, 2013 1:18 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Hi Bryan, > 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. Not too sure about making any of this normative. In my view, the only normative place where to specify at what locations the modules' attributes and elements are allowed in the core should be the specification of each module. Having modules.xml as a non-normative help would be fine, but I'm not sure we should normalize its usage. Because if we do and need to change, we'll go back to square one on having dependencies when updating modules. -ys
Original Message----- From: Schnabel, Bryan S [ mailto:bryan.s.schnabel@tektronix.com ] Sent: Sunday, December 8, 2013 10:03 AM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Bryan, Yves, just to clarify, the catalogue and schema LISTINGS are non-normative because they are provided for reader convenience, while the machine readable artifacts themselves are a normative part of the multipart product. So the listing of the validation aid should indeed go into a separate appendix but it should also be made clear that the artifact itself is not normative and should be distributed in a subfolder clearly marked as non normative.. dF is AFK, so that this had to be typed on his tough phone.. Call me at +353860222158 if this answer does not seem sufficient ;) On Dec 12, 2013 10:21 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi Bryan, > Hope this makes a bit more sense. I think it does. -ys
Original Message----- From: Schnabel, Bryan S [mailto: bryan.s.schnabel@tektronix.com ] Sent: Thursday, December 12, 2013 12:12 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Yves, I have a bad habit of trying to communicate an idea I am excited about during a period that I do not have adequate time to communicate clearly. In this case my brain wanted to say we should add a section on its use to the non-normative schema and catalog section. But my hurried fingers typed that we should add a normative section on its use (implied: to the schema and catalog section). So, let me be more careful and try again. If the modules.xml method is acceptable to the TC we should include it among the official schemas for download, state it as an official validation aid, and add it to the non-normative Schemas and Catalog Listings section (xliff-core-v2.0-wd03.html#coreListings) as A.4 Module Compliance Aid. I am not married to calling it " Module Compliance Aid." But nonetheless, I think it has a place in the spec. Hope this makes a bit more sense. Thanks, Bryan
Original Message----- From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Sunday, December 08, 2013 1:18 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation Hi Bryan, > 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. Not too sure about making any of this normative. In my view, the only normative place where to specify at what locations the modules' attributes and elements are allowed in the core should be the specification of each module. Having modules.xml as a non-normative help would be fine, but I'm not sure we should normalize its usage. Because if we do and need to change, we'll go back to square one on having dependencies when updating modules. -ys
Original Message----- From: Schnabel, Bryan S [mailto: bryan.s.schnabel@tektronix.com ] Sent: Sunday, December 8, 2013 10:03 AM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - validation 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php