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