OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  SC feedback: Validation

    Posted 12-20-2011 11:52
    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


  • 2.  Re: [xliff] SC feedback: Validation

    Posted 12-21-2011 21:56
    My overall thought:  I think schema validation is great, but not the highest priority.  What I mean is that we should minimize the risk that creating the schema becomes a bottleneck or point of contention.  It's far more important that we agree on the data model and semantics of XLIFF 2.0, than that we have a perfect schema for it.  One, we have plenty of work to do already.  Two (as Rodolfo notes in the cited link), not everything can be expressed in a schema anyway. How this affects us depends on our level of schema expertise.  Clearly, between Rodolfo, Yves, and probably others, we can create XML Schemas.  But it's hard for me to gauge our overall competency.  Can the Schema masters announce themselves? I ask because I've seen groups get bogged down when only a couple people could update the schema, or some case turned out to be particularly tricky.  I don't want this to happen to us.  I would rather have a loose schema plus additional wording in the spec, than a tight schema that slows us down. As to the schema language, based on my limited experience I would take RelaxNG in a heartbeat, and volunteer myself to become expert at it.  However, since XML Schema seems to have more currency than RelaxNG, and XLIFF 1.2 already used XML Schema, I don't know if it's the right choice.  I won't argue strongly for it.  As for XML Schema 1.0 versus 1.1, I'm not sure it's wise to rely on 1.1 before it's approved by the W3C. Andrew On Tue, Dec 20, 2011 at 3:51 AM, Yves Savourel < ysavourel@enlaso.com > wrote: 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


  • 3.  RE: [xliff] SC feedback: Validation

    Posted 12-21-2011 22:29
    Hi Andrew,   We already discussed the use of RelaxNG and discarded it. There is no need to discuss again at this time because the XML grammar technology has not changed since we decided to go with XML Schema and ignore RelaxNG.   Check section 3 of the tracking page in our wiki, http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Andrew Pimlott Sent: Wednesday, December 21, 2011 7:56 PM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] SC feedback: Validation   My overall thought:  I think schema validation is great, but not the highest priority.  What I mean is that we should minimize the risk that creating the schema becomes a bottleneck or point of contention.  It's far more important that we agree on the data model and semantics of XLIFF 2.0, than that we have a perfect schema for it.  One, we have plenty of work to do already.  Two (as Rodolfo notes in the cited link), not everything can be expressed in a schema anyway.   How this affects us depends on our level of schema expertise.  Clearly, between Rodolfo, Yves, and probably others, we can create XML Schemas.  But it's hard for me to gauge our overall competency.  Can the Schema masters announce themselves?   I ask because I've seen groups get bogged down when only a couple people could update the schema, or some case turned out to be particularly tricky.  I don't want this to happen to us.  I would rather have a loose schema plus additional wording in the spec, than a tight schema that slows us down.   As to the schema language, based on my limited experience I would take RelaxNG in a heartbeat, and volunteer myself to become expert at it.  However, since XML Schema seems to have more currency than RelaxNG, and XLIFF 1.2 already used XML Schema, I don't know if it's the right choice.  I won't argue strongly for it.  As for XML Schema 1.0 versus 1.1, I'm not sure it's wise to rely on 1.1 before it's approved by the W3C.   Andrew On Tue, Dec 20, 2011 at 3:51 AM, Yves Savourel < ysavourel@enlaso.com > wrote: 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  


  • 4.  Re: [xliff] SC feedback: Validation

    Posted 12-21-2011 23:26
    Thanks for the pointer.  I agree, no need to discuss it again. Andrew On Wed, Dec 21, 2011 at 2:28 PM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi Andrew,   We already discussed the use of RelaxNG and discarded it. There is no need to discuss again at this time because the XML grammar technology has not changed since we decided to go with XML Schema and ignore RelaxNG.   Check section 3 of the tracking page in our wiki, http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Andrew Pimlott Sent: Wednesday, December 21, 2011 7:56 PM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] SC feedback: Validation   My overall thought:  I think schema validation is great, but not the highest priority.  What I mean is that we should minimize the risk that creating the schema becomes a bottleneck or point of contention.  It's far more important that we agree on the data model and semantics of XLIFF 2.0, than that we have a perfect schema for it.  One, we have plenty of work to do already.  Two (as Rodolfo notes in the cited link), not everything can be expressed in a schema anyway.   How this affects us depends on our level of schema expertise.  Clearly, between Rodolfo, Yves, and probably others, we can create XML Schemas.  But it's hard for me to gauge our overall competency.  Can the Schema masters announce themselves?   I ask because I've seen groups get bogged down when only a couple people could update the schema, or some case turned out to be particularly tricky.  I don't want this to happen to us.  I would rather have a loose schema plus additional wording in the spec, than a tight schema that slows us down.   As to the schema language, based on my limited experience I would take RelaxNG in a heartbeat, and volunteer myself to become expert at it.  However, since XML Schema seems to have more currency than RelaxNG, and XLIFF 1.2 already used XML Schema, I don't know if it's the right choice.  I won't argue strongly for it.  As for XML Schema 1.0 versus 1.1, I'm not sure it's wise to rely on 1.1 before it's approved by the W3C.   Andrew On Tue, Dec 20, 2011 at 3:51 AM, Yves Savourel < ysavourel@enlaso.com > wrote: 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  


  • 5.  RE: [xliff] SC feedback: Validation

    Posted 12-22-2011 09:38
    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


  • 6.  RE: [xliff] SC feedback: Validation

    Posted 12-22-2011 10:06
    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


  • 7.  RE: [xliff] SC feedback: Validation

    Posted 12-22-2011 12:35
    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


  • 8.  RE: [xliff] SC feedback: Validation

    Posted 12-22-2011 13:01
    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


  • 9.  RE: [xliff] SC feedback: Validation

    Posted 12-22-2011 13:34
    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


  • 10.  RE: [xliff] SC feedback: Validation

    Posted 12-22-2011 14:00
    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


Related Content