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: [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?


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