Chet,
My recollection when we last asked “who-wins-when-the-spec-and-schema-have-contradictory-markup” – is that the spec is authoritative.
Do I recall correctly?
Thanks,
Bryan
From: [mailto:]
On Behalf Of Yves Savourel
Sent: Monday, August 19, 2013 7:59 AM
To:
Subject: RE: [xliff] FW: [xliff-comment] Xliff 1.2 transitional schema validation behaviour with extended nodes
Hi Tom,
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:sequence maxOccurs="unbounded">
<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
<xsd:element ref="xlf:file"/>
</xsd:sequence>
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.
Cheers,
-yves
