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] Metadata extensibility ballot


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.
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]