RE: [xliff] FW: [xliff-comment] Xliff 1.2 transitional schema validation behaviour with extended nodes

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

 

From: Chet Ensign [mailto:]

Sent: Monday, August 19, 2013 2:00 PM

To: Schnabel, Bryan S

Cc: Yves Savourel; ; Dr. David Filip ()

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 <> 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:
 [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

 

-- 

/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