[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] FW: [xliff-comment] Xliff 1.2 transitional schema validation behaviour with extended nodes
That’s very possible. I was not there for the errata, and I haven’t checked.
I just wanted to be sure Tom knew about it in case that was an issue for 2.0. But visibly it’s not.
Yves, wasn't this addressed in the published errata for 1.2? i am not sure just that you remember seeing it somewhere, might it be the Errata?
Dr. David Filip
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
On Mon, Aug 19, 2013 at 3:58 PM, Yves Savourel <email@example.com> wrote:
Notes are inline…
For our 2.0 efforts, I have scripts to parse both the documentation and the schema, to find discrepancies between them. I can’t guarantee that it will catch every problem, but it’s a useful backup to our collective diligence. Similarly, to ensure consistency the tree diagrams will be generated directly from the schema, as soon as I work out a few details.
YS> Great. Sounds like a much better way to get the schema and the specification synchronized.
As for the original problem report in 1.2, it is as described. The documentation for the <xliff> element says:
One or more <file> elements, followed by
Zero, one or more non-XLIFF elements.
while the schema says:
<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
I’m not sure what the appropriate response would be. And I’m not sure what it says about current implementations that the issue is only reported now.
YS> I vaguely recall that somewhere there is a statement say which one of the schema or the specification wins if there is a difference like here. Or maybe we added that for 2.0?
In any case: adding elements outside <file> is probably not a very good practice since files can be split per <file> by some tools. So that’s probably why nobody caught this before.