RE: [xliff] FW: [xliff-comment] Xliff 1.2 transitional schema validation

Thanks Chet. I’m glad I asked. I will respond to Alberto Abad on the issue.

From: Chet Ensign [mailto:chet.ensign@oasis-open.org]
Sent: Monday, August 19, 2013 2:00 PM
To: Schnabel, Bryan S
Cc: Yves Savourel; xliff@lists.oasis-open.org; Dr. David Filip (David.Filip@ul.ie)
Subject: Re: [xliff] FW: [xliff-comment] Xliff 1.2 transitional schema validation behaviour with extended nodes

Actually no, other way around. The TC Process sect 2.18 states "All normative computer language definitions must be provided in separate plain text files... Where any definition in these separate files disagrees with the definition found in the specification, the definition in the separate file prevails."

/chet

On Mon, Aug 19, 2013 at 4:13 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:

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: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Monday, August 19, 2013 7:59 AM
To: xliff@lists.oasis-open.org
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

--

/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn: http://linkd.in/OASISopen
Twitter: http://twitter.com/OASISopen
Facebook: http://facebook.com/oasis.open

xliff message