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] <mrk> attributes validation

Hi Tom and Yves,

I may not be completely understanding the use case, but if i think the situation where attributes are optional or required depending on the type is a case of "co-occurrence constraints" http://www.w3.org/wiki/Co-occurrence_constraints - which I believe is solved in XML Schema 1.1.

I don't think we can try to do an XML Schema 2.0 because 1.1 is the latest recommendation.

But I think no matter what language we choose to validate XLIFF 2.0, there will be shortcomings. This is not just an XLIFF limitation. I think several other standards face the same challenge. To me it seems like there are three levels of success when evaluating the compliance of a document to its specification (from least-to-most):

(1) XML validity
(2) Processing requirements validity
(3) Best practices adherence

In our case I think we can solve (1) with XML Schema 1. I think we can solve (2) by hoping for XLIFF checker tools that I suspect would turn up after the approval of XLIFF 2.0. And I think (3) is a moving target and cannot be expected to be evaluated by tools, but might be seen as a distinguishing characteristic or claim certain products or processes can make.



From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Tom Comerford [tom@supratext.com]
Sent: Friday, September 27, 2013 10:00 PM
To: 'Yves Savourel'; xliff@lists.oasis-open.org
Subject: RE: [xliff] <mrk> attributes validation

Hi Yves,

The specific answer, re: the <mrk> element, is that we can’t enforce conditionally-required attributes through schema validation. If the attribute is defined as optional, but it is deemed to be required for a particular usage, we have no way to enforce that through the schema.

The alternative approach would have been to create separate elements, each with attributes set to required or optional according to the usage – multiplying the complexity. Even with that approach, I believe there are other processing requirements throughout the spec that could not be checked through schema validation.

So the general answer is that an additional tool will be needed to supplement schema validation for evaluating whether an XLIFF file fully conforms to the specification. At the moment, that tool doesn’t exist.



From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Friday, September 27, 2013 10:23 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] <mrk> attributes validation

Hi Tom, all,

The <mrk> element has several attributes that are optional or required depending on the type<http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/xliff-core-v2.0-csprd02.html#annotations>.

Does the schema validates those combinations? I recall that we had some discussions about doing that with the version 2.0 of XML Schema.

The more general question is: if we cannot validate everything with the schemas, how do we validate XLIFF 2.0 documents?



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