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.
Cheers,
-yves