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] csprd02 comment 138 - schema ambiguity in core and matches

Hello David,


It's true that the specified order is unambiguous, but the referenced elements are optional and that makes all the difference. Formally the term is "unique particle attribution", where the element reference in the schema is a particle and an occurrence of the element in a document conforming to that schema must be attributable to exactly one particle in the schema. As it's currently defined, in an XLIFF document an occurrence of a non-core element can be attributed to either the explicit reference or to the wild-card reference in the schema.


Note that <file> also explicitly allows non-core elements, all optional and in a specific order; and there's also an extension point. In this case, though, there's no ambiguity because at least one of <unit> or <group> must occur before the extension point. Any non-core elements can be attributed correctly based on whether they occur before or after the required elements.


I believe Relax NG eliminates the problem, but I haven't thought through the specific approach (or, for that matter, what other implications there may be if we were to choose to change the schema language). If we have XLIFF documents with an XSD schema, then the ambiguities have to be resolved. Tools that supplement the validating parser can be used to check conditions (like acceptable locations for optional non-core elements) that XSD doesn’t support, but they don’t eliminate the validation error.






From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Tuesday, November 12, 2013 12:33 PM
To: Tom Comerford
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] csprd02 comment 138 - schema ambiguity in core and matches



On Tue, Nov 12, 2013 at 3:21 AM, Tom Comerford <tom@supratext.com> wrote:

A validating parser cannot unambiguously determine whether any occurrence of the referenced element satisfies the explicit reference, or the wild-card <xs:any> token. Thus, strict validation of the schema fails.

How come?


Order of elements (unlike attributes) is not arbitrary in XML, so how come that validators cannot determine this. There should be a standard way to check for presence of a number of allowed modules before the wild card starts applying.


If xsd cannot do this, we MUST supply a schema-like mechanism for automatically checking this..


Yves suggested Schematron or NVDL, maybe relax ng?




Dr. David Filip



University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

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