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] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements

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.


Dr. David Filip
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

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