RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

>> It makes no sense to me that an optional module MUST 
>> be preserved. It's not optional anymore.
>
> It is optional, as you do not need to support it, see my previous 
> definition of support as read, understand, process, write 
> as per its PRs.

If a tool must do something with an element, by definition, it does not have an option.
Here you are forcing all the tools to at least read and write, which, according your own definition, is part of "support".


>> Furthermore, if core-only tools cannot remove a module, I assume the 
>> tools aware of the module can. So we would have the absurd situation 
>> where a tool that doesn't support module ABC must preserve it, but 
>> the tool XYZ that supports that module can remove it.
>
> This situation is not at all absurd. Module aware tools can remove module 
> elements AS PER its PRs. 

The PRs regarding deletion are only when you re-segments.
Any tool must be able to remove an element like a <matches>, even if there are no PRs that says it should.
Same for glossaries, etc.


> AND as per our definitions of module and extension, they also CANNOT POSSIBLY 
> have a VALID reason to modify modules, because if they had it they would 
> have to support it, i.e. understand its PRs.

Wrong: there are many valid reasons to remove a non-core element even if you don't understand it.
Rodolfo described an example. I can provide you with others.


>> That doesn't make them special. I want tools to be able to get 
>> rid of any non-core constructs if they see a need for it.
>
> This is surprising to me, as you first wanted to protect 
> unconditionally both modules and extensions.

Indeed. And I was wrong: SHOULD preserve is better.
If I get enough logical arguments to change my opinion I do.
Maybe you should consider that too.


>> The reason you listed for tools to get rid of the elements of a custom namespace 
>> are just as valid for the elements of a module.
>
> I do not think they are. The modules are TC vetted (they are not ANYTHING that can 
> come through a random custom extension) 

No. There are "anything" for a tool that doesn't support the module. For that tool a module is as "random" (whatever that means) as an extension.

It's not because the TC thinks the module is fine that the users of a tool should have the same opinion.
There are many reasons they may want to not read those modules: speed, storage in DBs, size, etc.


> and module roundtrip cannot be guaranteed without unconditional protection 
> from tools that do not support/understand it. This invalidates the idea of the 
> module and prevents further development of the standard by adding modules.
> Who would care for adding modules if the roundtrip was not guaranteed.
> Modules are optional only as long as you do not cover their functionality.
> If you do, they are as non-negotiable as the core is.

No module is guaranteed to do a round-trip, where did you see that?
Modules are optional: tools *should* do their best the preserve them, but it should not mandatory.
 

> If there is a way to preserve (in case the successor carrier element can 
> be identified), the module MUST be preserved and the extension SHOULD as 
> per the general rule, if the special rule does not say otherwise.

This is the crux of the problem: you simply cannot force tools to preserve something that is optional and they may have valid reason to get rid of. The TC cannot define what a valid reason is, only the tools can.


 
>> The distinction between modules and custom namespaces exists:
>> - modules always have a schema.
>> - modules are documented and backed by the TC.
>> - modules could exist in places extensions could not.
>> Those are all incentives for tool vendors to migrate their 
>> extensions to modules.
>
> The effect of these incentives is thwarted if the modules are not 
> protected from tools that do not understand them. or if they 
> have the same level of protection as extensions.

The fact you could have a module where you cannot have an extension has nothing to do with protecting it or not; having a schema or not, having documentation or not; having interoperability or not: All those things are incentives that have nothing to do with whether the module MUST or SHOULD be preserved.

The bottom line IMO is:
 
- We cannot use "MUST preserve" for something that is not core.
- There are no technical reasons to have separate generic PRs (e.g. PRs for core-only tools) for modules and custom extensions.


Regards,
-yves



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org