Re: [xliff] Metadata extensibility ballot

[David Walters <waltersd@us.ibm.com>]

An additional comment about this.

>  In the inline markup we have <mrk translate='yes'>...</mrk> why not use <mrk its:translate='yes'>?

1. An XLIFF application knows that the XLIFF "translate" attribute defines whether the content is translatable or not, since it is part of the XLIFF specification.  So ALL XLIFF applications would be expected to handle this element's content the same way
   
2. An XLIFF application does not necessarily know that the "its:translate" attribute has the same functionality. So each XLIFF application could handle the element's content differently.  The element's content may be translatable in one application and non-translatable in another application.

Any namespace extensions within <source> and <target> cannot affect how the content is interpreted and must be completely ignorable by an XLIFF application.


David

Corporate Globalization Tool Development
EMail:  waltersd@us.ibm.com           
Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721

CHKPII:                    http://w3-03.ibm.com/globalization/page/2011
TM file formats:     http://w3-03.ibm.com/globalization/page/2083
TM markups:         http://w3-03.ibm.com/globalization/page/2071

Yves Savourel ---06/15/2012 08:28:28 AM---Hi Kevin, > In line with Rodolfo's point here, is there any reason why the TC

From:	Yves Savourel <ysavourel@enlaso.com>
To:	<xliff@lists.oasis-open.org>
Date:	06/15/2012 08:28 AM
Subject:	[xliff] Metadata extensibility ballot
Sent by:	<xliff@lists.oasis-open.org>

---

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