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

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

Rodolfo,
regarding extensibility in segments.. I think there is a broad
consensus that no custom elements should be allowed in segments. I am
not so sure about extensibility of attributes on generic masking
markup. But I believe that the markers should remain fully extensible
for annotations of various kinds that we cannot foresee.

Cheers
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 7:24 PM, Rodolfo M. Raya <rmraya@maxprograms.com> wrote:
>
> Hi Yves,
>
> There is a substantial difference between custom extension and official
> XLIFF modules: the schema of an official module is available.Validating
> something that comes from a module is possible. Can't say the same regarding
> custom extensions.
> I don't care about custom extensions as long as they are not present in
> <segment> elements.
>
> Regards,
> Rodolfo
> --
> Rodolfo M. Raya
> Maxprograms http://www.maxprograms.com
>
>
>
> -------- Original Message --------
> Subject: RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and
> processing requirements
> From: Yves Savourel <ysavourel@enlaso.com>
> Date: Thu, October 25, 2012 3:19 pm
> To: <xliff@lists.oasis-open.org>
>
> 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
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional
> commands, e-mail: xliff-help@lists.oasis-open.org