[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Metadata extensibility ballot
Yves, Are you suggesting we allow third party namespaces in <source> and <target> ? I would not allow any third part namespace inside <source> or <target>, not even ITS. That could completely destroy interoperability. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com > -----Original Message----- > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf > Of Yves Savourel > Sent: Friday, June 15, 2012 10:28 AM > To: xliff@lists.oasis-open.org > Subject: [xliff] Metadata extensibility ballot > > Hi Kevin, > > > In line with Rodolfo's point here, is there any reason why the TC > > cannot consider adopting the ITS recommendations wholesale as a > > standard module in the future? > > It's not always possible. For example: > > In the inline markup we have <mrk translate='yes'>...</mrk> why not use > <mrk its:translate='yes'>? > > The answer: when <mrk> has overlapping code or annotations, or is split by a > segment break, we have to use a notation that is different: <sm>/<em> to > indicate the start/end markers. So you would end up with <sm > its:translate/>...<em/>. But the scope of its:translate is the content of the > element where it is declared, and in that case it's empty. When we use our > own attribute we can control the semantic associated to it (here that it > applies up to the corresponding <em/>). It would be rather confusing to > have to use different attributes on different notations of the same feature. > Having to use different notations is bad enough. > > So I don't think we can apply ITS wholesale. We could certainly use the ITS > namespace directly when it make sense and when it's applicable. > > > One important aspect in favor of allowing 'custom' namespace would be also > agility, for example, Rodolfo pointed out: > > >> A strong XLIFF 2.0 based on XLIFF defined elements only can be > >> enhanced at any time in the future by publishing new modules as we > >> see fit. > > Integrating new modules will take time: we would have to change the > schema to allow them explicitly, possibly change the version of XLIFF (2.1, > 2.2, etc.) OASIS has some process to do those things, and the fastest of the > track is probably not necessarily fast enough. > > Allowing custom namespaces at the spots where <metaHolder> would be > allowed permits a simpler way to evolve XLIFF. You don't have to change the > schema. The namespace can be use that way while it is analyzed and > integrated in the collection of XLIFF modules, and then it becomes a module. > Note also that going from your own custom namespace to an XLIFF module > would be very easy: just a URI change. In the other hand going from your > custom data in <metaHolder> to a module is more complicated. > > > And one last note on this other note from Rodolfo: > > >> There is no real need for allowing third party namespaces at the risk > >> of huge interoperability problems like we see today due to bad > >> implementations. > > Once again: The interoperability issues of 1.2 are because there are bad use > of extensions, not because there are extensions. Many tools use custom > namespaces correctly and should be allowed to continue. Actually I would > contend that not supporting custom extensions can be a show-stopper for > some tools to adopt 2.0: if the feature is not in 2.0 and metaHolder cannot > support it, what do they do? > > Cheers, > -yves > > > > > > --------------------------------------------------------------------- > 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]