OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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

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." 


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



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?






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"/>


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.





Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]