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

["Dr. David Filip" <David.Filip@ul.ie>]

Yves,

same as Rodolfo, I think that it is a substantial difference that
XLIFF modules have an OASIS warranted published schema, whereas
extensions don't.
This is also what I mean when I say that support of extensions can be
negotiated outside XLIFF TC.
Some authorities behind namespaces (and underlying semantics!) are
better than others, so some people might be happy to validate against
a W3C published schema rather than against a schema published by a
private initiative or a single tools vendor. And why should people
bother at all to preserve stuff that has no published schema at all?
Still a Corporate buyer or an LSP can negotiate within their supply
chain that their extensions won't be deleted. They might even
negotiate that they will be supported, ideally as an OASIS warranted
XLIFF module :-)

I see the point that applications supporting only core might have
trouble discerning between real modules and "unsupported modules".
Still I do not subscribe to this terminology, as it might obscure the
substantial difference between a module and an extension.

This must be resolved by a specific requirement not to delete modules
based on schema validation. Obviously schema is not enough for
processing, and sure enough we do not want the core only applications
to process the modules, we only tell them to preserve them and for
that end, schema should be enough.
Besides if they are lazy they can decide not to validate non-core and
preserve everything at points where modules or extensions are allowed.
There is no harm in it. On the other hand if someone multiplies the
size of an xliff file by inclusion of some verbose proprietary mark up
it is totally legitimate to delete it to preserve own storage
resources (the use case might be e.g. building an MT training corpus,
or simply unwillingness to clutter machines of my translators with
rubbish, and rubbish it can be if it is ANY extension).

If extensions will have the same level of protection as modules,
implementers will rely on extensions rather than push modules into
common space. And this is fundamentally bad from my point of view.

Extensions can compete for feature coverage with other extensions, but
MUST NOT compete with features covered by core AND modules.

Modules are documented in the same spec as core and other modules,
along with a schema that allows to recognize them as protected.

I believe the following is a substantial question:
What good can come from preserving an extension if you must not rely
on it for merging back?


The general Processing Requirements should go like this

Core MUST be processed.
Module MUST be processed if supported, or otherwise preserved.
Extension MAY be processed, preserved, or deleted. [my preferred way]

Or we might want to say something like:
Extensions SHOULD NOT be deleted if their schema is declared in the
XLIFF document AND publicly accessible.
Otherwise Extensions MAY be processed, preserved, or deleted.

I believe that SHOULD NOT is the right normative word here, as in most
cases it is good not to delete, still people can decide to delete if
they have their reasons. It is like us using : for a non-namespace
prefix, we have a good reason for it, or do we? :-).

Rgds
dF




Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie


On Thu, Oct 25, 2012 at 6:19 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
> Hi David, all,
>
> As we mentioned at the face-to-face meeting, the processing requirements for extensions certainly need to be worked on. The ones in the specification are, as you noted, just the initial proposal.
>
> As for whether or not user agents should be able to delete extensions or not:
>
> One major point to remember is that a custom extension ABC is not distinguishable from an official XLIFF module XYZ for the user agents that do not support that module. They both are just some elements/attributes in a unknown namespace.
>
> You can see this from a different direction:
> Forget about custom extensions. Think only about XLIFF modules from the viewpoint of tools supporting only the core.
> We must have some processing expectations to preserve such modules.
> This is what we need to define.
> Then when it's done, we can just say the same apply to custom extensions because there is no logical reason to treat them differently.
>
>
>> If someone wants to effectively use extensions for broader
>> interoperability as opposed to internal processing aid [which is
>> fully OK], they should seek to warrant their survival with other
>> means than a "carte blanche" from XLIFF TC.
>>
>> For instance, preserving ITS based extensions should be warranted
>> by the W3C recommendation (and its implementers) rather than the
>> OASIS stanadard and its implementers [the implmeneter groups can
>> obviously overlap].
>
> I'm afraid that make no sense to me: XLIFF tools common behavior is driven by the processing requirements set in the XLIFF specification, not by anything else.
>
> Let's say we have a custom element for some ITS data category, we try it out, etc.
> Then 4 months later, we decided it works fine and it's stable and we'd like to make it an official XLIFF module.
> We go through that process and the extension becomes an official module.
>
> Why in the world a tool that supports only the core should have a different behavior before and after the extension become a module? For all we know at this point the element may even keep the same namespace. From the tool viewpoint, once again, there is no difference between a module it does not support and a custom extension.
>
> So, I think we should stop thinking about the word "extension" and focus on getting the PR done. If it can help, think the extension is a "unsupported module". I'm going to use that term from now on :)
>
> And with that in mind, I'd like very much the unsupported modules to be preserved whenever it's possible.
>
> We may have PR related to how to behave with unsupported modules in specific places too. For example, it may be good to define what a tool do when removing an <mrk> element that has a ref attribute pointing to some element in the same unit. that element should probably be remove as well (assuming it's not used by another <mrk>).
>
> Cheers,
> -yves
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org
>