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] Input to discussion on Conformance

Hi Rodolfo, Yves, all,

Thanks for your comments.

One thing I derive from it is that you like my suggestion to treat processing requirements separately. So I suggest to continue the discussion with a focus on what I suggested to call " Markup Conformance".

I understand the points you make about the four types of Markup Conformance - I would completely agree if the state of existing implementations would be different from what was depicted in the presentations at the XLIFF Symposium. However, I think - given the current state of affairs - the fine grained distinction which I propose is important:

	It enables very targeted communication related to conformance. It allows providers of XLIFF files and applications to make very targeted statements. 

This allows interested parties to clearly figure out if a certain type of interoperability already is possible or not. They will be able to figure out whether for example a tool chain involving tool A and tool B is viable (e.g. since both tools "only" conform to "n-un") - since for example information that is carried in extensions will survive/can be utilized.


-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Montag, 25. Oktober 2010 19:35
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Input to discussion on Conformance


I would agree with Rodolfo.
As long as they are well-formed, and only in the places where XLIFF allow them, custom extensions shouldn’t matter for conformance.
It seems also logical that we have a binary result: either a conformant document or a non-conformant one.

For processing conformance: I think it’s important to have processing expectations and express them in clear clauses in the specification. But it seems that this goes beyond what OASIS sees as “conformance”, and we could treat this separately?

I think we are going to have difficulties to validate processing conformance. We could offer a set of input files in different formats and a corresponding set of XLIFF documents that illustrate the processing expectations, but beyond that I don’t think we could have a tool that automatically verifies if the XLIFF document follow them or not.


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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