RE: [xliff] SC feedback: Validation

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hi again,

We should not mention in the standard how to validate an XLIFF file or recommend to check the code of any given tool/library for learning how to write a validation tool.

In the standard we define the elements and attributes that belong to XLIFF, define what foreign elements and attributes can be used inside XLIFF and what we expect to find in an XLIFF file. We can add some processing expectations in the specification document but we cannot write a monster document covering every aspect of XLIFF.

Today we know some of the processes that could be applied to an XLIFF document and we might try to document expected behavior for them. New processes can appear tomorrow and we still don't know what may happen.

An important part of the specification is the conformance clause. There we can write that an XLIFF file must be valid according to the accompanying schema and must follow the processing expectations included in the various parts of the document. Beyond that, there isn't much we can do.

No matter how hard we work to make the specification unambiguous, there will always be different interpretations. 

In the future you may find in the market different tools that support XLIFF 2.0 but you will not be able to achieve total interoperability between them. You will also find that files from a given tool may not always follow the specification and there will be nothing you can do about it except prepare your own tool to support XLIFF files with unbelievable problems.

We can expect to release a better version of XLIFF, not a perfect version of XLIFF.

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com


> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Estreen, Fredrik
> Sent: Thursday, December 22, 2011 11:33 AM
> To: Rodolfo M. Raya; xliff@lists.oasis-open.org
> Subject: RE: [xliff] SC feedback: Validation
> 
> Hi Rodolfo,
> 
> of course the TC cannot tell anyone if they can or cannot write a validation
> tool. My point is that we need to specify how an application can validate an
> XLIFF 2.0 document. The means to do so should be as simple and un-
> ambiguous as possible. It should also be possible on any reasonable platform
> supporting XML.
> 
> Writing in the standard that you should look at the source of this or that
> program and implement its algorithms for your self is not something I would
> support. Saying that the proper way is to use a specific tool not supported or
> un-suitable for some platforms is also not acceptable to me.
> 
> Any re-implementation is likely to introduce bugs or interpret things
> differently and that is precisely what you want to avoid with validation.
> 
> I strongly believe that XML standards should be platform independent and
> that includes how to validate incoming or outgoing documents.
> 
> As I wrote in my initial mail, a tool to test the conformance of an application
> does not need to meet these requirements. There it is enough if it is
> supported on at least one commonly available platform. It is of course nice if
> it works on more than one platform but not a requirement. Here a tool like
> XLIFFChecker makes a lot of sense.
> 
> Regards,
> Fredrik Estreen
> 
> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Rodolfo M. Raya
> Sent: den 22 december 2011 14:01
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] SC feedback: Validation
> 
> Hi Fredrik,
> 
> XLIFFChecker code is open source and anyone in need of a validating tool can
> use it as a starting point. It can be ported to other languages by those that
> want to use it in an unsupported platform. The code is published under EPL
> and there are no restrictions for using it.
> 
> Anyone can write another tool or library for validating XLIFF files. The XLIFF
> TC can't forbid doing so. Having more options for validating XLIFF files could
> be nice.
> 
> Regards,
> Rodolfo
> --
> Rodolfo M. Raya       rmraya@maxprograms.com
> Maxprograms       http://www.maxprograms.com
> 
> 
> > -----Original Message-----
> > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
> > On Behalf Of Estreen, Fredrik
> > Sent: Thursday, December 22, 2011 10:35 AM
> > To: Rodolfo M. Raya; xliff@lists.oasis-open.org
> > Subject: RE: [xliff] SC feedback: Validation
> >
> > Hi Rodolfo,
> >
> > I'm aware of XLIFFChecker and have looked at the source code. But
> > there are places where I could not use it or where I would not want to
> > use it. If we disregard the UI part which is even harder to support,
> > and probably not wanted in a pure validator used by other apps, I
> > still see a lot of portability issues.
> >
> > For example iOS and WP7 devices due to no java support at all as far
> > as I know.
> >
> > For Android you need to repackage some of the third part libs you use
> > to be able to run it on Dalvik VM (Xerces for example).
> >
> > In most cases as an application developer I do not want to run an
> > external application, so a library should be provided. For web server
> > and database stored procedures I really do not want to call out from
> > the native environment and launch a new process to do validation. And
> > apps that support java natively would most probably want to reuse
> > their existing VM and not pay the overhead of launching a new one for
> each validation.
> >
> > A java library would probably work well for apps written in Java but
> > not for others.
> >
> > I doubt a developer of a .NET app would like to add a dependency on a
> > Java VM to deploy his otherwise totally .NET application. Same thing
> > with most other languages that are not Java.
> >
> > The list goes on as the number of platforms and environments is ever
> > growing.
> >
> > Regards,
> > Fredrik Estreen
> >
> > -----Original Message-----
> > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
> > On Behalf Of Rodolfo M. Raya
> > Sent: den 22 december 2011 11:06
> > To: xliff@lists.oasis-open.org
> > Subject: RE: [xliff] SC feedback: Validation
> >
> > Hi Fredrik,
> >
> > XLIFFChecker is a Java application and you can find executable
> > versions for Windows, Mac OS X and Linux in my web site. The source
> > code is also available for download, so you can run it on any platform
> > where java is supported.
> >
> > Regards,
> > Rodolfo
> > --
> > Rodolfo M. Raya       rmraya@maxprograms.com
> > Maxprograms       http://www.maxprograms.com
> >
> >
> > > -----Original Message-----
> > > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
> > > On Behalf Of Estreen, Fredrik
> > > Sent: Thursday, December 22, 2011 7:38 AM
> > > To: Yves Savourel; xliff@lists.oasis-open.org
> > > Subject: RE: [xliff] SC feedback: Validation
> > >
> > > Hi Yves, All,
> > >
> > > I'm strongly in favor of using a schema as the primary way to
> > > validate Xliff documents. I do not like the idea to rely heavily on
> > > external applications to do the validation.
> > >
> > > For the purpose of testing applications for standards conformance
> > > including if they abide to the processing expectations set forth in
> > > the standard I do endorse a separate application. That is likely the
> > > only reasonable path to take.
> > >
> > > The reason that I do not want it for the everyday validation by
> > > Xliff supporting applications is that it will most likely not be
> > > portable. I doubt that the TC has the resources to develop and
> > > maintain validation tools and libraries useable by any application
> > > on any platform that might want to validate Xliff. If no tool is
> > > provided for a platform it would lead to applications not validating
> > > or developing their own validation code. Even if there is a
> > > reference source code available the new implementations might (or in
> > > my experience will) behave differently leading to many definitions of
> valid in the field.
> > >
> > > I would propose doing a schema in XML Schema 1.0 and another one
> > > augmented by the extensions provided by XML Schema 1.1. This should
> > > be a relatively "simple" task since 1.1 will interpret a 1.0 schema
> > > the same way it worked before. So it should be technically possible
> > > to just augment the 1.0 version with the new features. This would
> > > give us a basic validation that works for almost all cases today and
> > > a better validation that will become available to applications as
> > > the new schema becomes available on their platform or framework. To
> > > reduce the initial work we should probably wait with doing 1.1 until
> > > we have a
> > reasonably stable 1.0 version.
> > >
> > > Regards,
> > > Fredrik Estreen
> > >
> > > -----Original Message-----
> > > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
> > > On Behalf Of Yves Savourel
> > > Sent: den 20 december 2011 12:52
> > > To: xliff@lists.oasis-open.org
> > > Subject: [xliff] SC feedback: Validation
> > >
> > > Hi everyone,
> > >
> > > During the last inline SC meeting we discussed the validation for XLIFF:
> > >
> > > Which mechanism to use (schema or schema + dedicated tool), if XSD
> > > which version, what about RelaxNG? How much of this should be taken
> > > into account when designing our formats, etc.
> > >
> > > There was a consensus that this needs to be bring up at the TC level
> > > and settled soon so we can know the guideline when working on the
> > > specification.
> > >
> > > There has been some discussion of this before.
> > > e.g. Rodolfo email here:
> > > http://lists.oasis-open.org/archives/xliff/201111/msg00046.html
> > >
> > > cheers,
> > > -yves
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: xliff-help@lists.oasis-open.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: xliff-help@lists.oasis-open.org
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org
>