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] To extend or not to extend. Was: [xliff] Definition of "core" and "modules"

I think we're all in agreement then. Your mention of using <ph> is what I had in mind by saying that this made-up format would be treated just like IDML, Word, etc.

I could see cases where other stuff could be added in <source> that wouldn't create a problem, but this is clear example of where it would definitely cause a problem. I think your principles (and a discussion I just had with Rodolfo) address this issue to my satisfaction (meaning I am now clear on the principle, not that anyone had to change anything).


On Nov 17, 2011, at 11:22 , Yves Savourel wrote:

Hi Arle,
Thanks for the example. It’s a good illustration of something that, I think, should not be allowed in 2.0 (just like it is not allowed in 1.2).
You are correct: the extra markup in <source> prevents the core to work. So it shouldn’t be done. Like Rodolfo noted: it is a basic principal that we should maintain.
If people want to have complex modules that do work in XLIFF (in <source> or elsewhere) they should be in the TC right now so their requirements can be taken into account.
But there is another solution: technically all that can likely be represented with one or few extension attributes in a <ph> element of XLIFF and possibly a structure outside <source>. And that whole thing could then be an extension that would not prevent the core to be processed normally.
Maybe it wouldn’t be pretty or elegant, but it would keep interoperability alive.
I think there is nothing wrong for a specific vertical to come up with additional features for XLIFF, as long as they can be treated like an optional module and follow the requirements for that. For example:
-   Cannot break the core
-   Cannot represent features that are available in either the core or one of the official optional module.
-   Maybe other things…
And, obviously, if anyone would like to see their module be part of the standard ones, I would encourage them to join the TC and work with us on that.

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