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] Implementing extensions

Hi again,
Regarding items #6 and #7, making the schemas and documentation public would help achieving interoperability.
Having the schema at hand would make complete XML validation possible. I wish I could say that we would be able to do a full XLIFF validation, but that would be sadly impossible. 
We do need full XML validation. Today when users try to open their files in the originating tool after they have been translated with a different program, they don't know if their files will be accepted. I've seen files rejected for these reasons:
 - because the order of attributes in a custom element is different than what the tool expected
 - because a custom element was not updated at translation time
 - because the program expected a custom element that is missing
If the user can validate the XML, the tool vendor will have to fix the tool and make it accept a valid file.
Looking from another angle, our work is released under Royalty Free an RAND terms. I would like that any extension to our work be released under the same terms. When I write an XLIFF editor, I expect it to be able to handle XLIFF files created by other tools. If those XLIFF files include secret stuff, I have to either do reverse engineering or hope that my customer doesn't have problems with the translated XLIFF. I'm tired of that.
XLIFF is an open format. Let start asking to those that extend OUR format to make their extensions open as well.
Maxprograms http://www.maxprograms.com
-------- Original Message --------
Subject: RE: [xliff] Implementing extensions
From: Yves Savourel <ysavourel@enlaso.com>
Date: Wed, March 21, 2012 2:39 pm
To: <xliff@lists.oasis-open.org>

Hi Rodolfo, all,
A very good list!
I agree with all, with some reservations for #6 and #7.
For #6: I just wonder if it shouldn’t be “extensions SHOULD be public and documented” (more explanations on that on the two other emails I just posted)
For #7: I have no idea if anything IPR-related rules need to be specified. It’s good to bring up that topic though.
From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com]
Sent: Wednesday, March 21, 2012 11:12 AM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] Implementing extensions
Some points to keep in mind regarding extensibility:
  1. It must be safe to ignore custom extensions while processing an XLIFF file;
  2. Extension points should not be allowed in critical elements, like <source> or <target>;
  3. Extensions must not be used instead of XLIFF standard features;
  4. A tool that generates XLIFF files with custom extensions must be able to accept an XLIFF file processed with other tool as long as the received file is valid XLIFF;
  5. A tool that uses custom extensions should not expect that other tools update custom data while processing an XLIFF file;
  6. XML schemes that define custom extensions must be public and documented;
  7. Any custom extension used in an XLIFF file must be published under the same IP terms the XLIFF standard is published and be freely redistributable;
  8. Custom extensions are subject to standard rules for XML handling and the recommendations regarding XML usage included in the XLIFF specification.
Best regards,
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
-------- Original Message --------
Subject: [xliff] Implementing extensions
From: Yves Savourel <ysavourel@enlaso.com>
Date: Wed, March 21, 2012 8:52 am
To: xliff@lists.oasis-open.org

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