W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > November 2012

[Issue-55] XLIFF mapping

From: Yves Savourel <ysavourel@enlaso.com>
Date: Thu, 8 Nov 2012 07:45:28 -0700
To: <public-multilingualweb-lt@w3.org>
Message-ID: <assp.0659bfc98f.assp.06599c2ec6.006c01cdbdbf$b26921d0$173b6570$@com>
Hi all,

Just an update on the XLIFF mapping.

We needed to see if the XLIFF TC was going to allow native ITS markup in <mrk>, as it is the only way we can really support some data categories as XLIFF metadata and at the same time allow an ITS processor to work with the file.


The proposal led to some discussion at the last TC meeting on Thursday and some email discussion.

It looks like extensions would not be allowed in <mrk> but the necessary ITS attributes may be allowed there through a module.

This led to other discussions about what should and should not be allowed in a module and even how modules will be adding to XLIFF once the core is done.

You can read all this here:
https://lists.oasis-open.org/archives/xliff/201211/maillist.html
(although you probably want to avoid it)

There *seem* to be some agreement (at least no valid argument against) that native ITS attribute should be OK as a module in <mrk> when ITS 2.0 is done.

It's hard to say if/when there will be a final formal agreement. But at this point I think we have to proceed with the assumption that we will be able to use ITS attributes in <mrk>.

Maybe David has another opinion?


I would however still recommend to have a pointer version of any attribute that reference a standoff annotation.

The reason is that otherwise the reference URI has to be set in two different attributes: the native ITS one and the native XLIFF one. Why is that? Because XLIFF processor--even if they do not support the ITS module--must be able to delete the annotation and therefore know what the URI is to also delete the standoff part. Such tool have processing requirements to use the ref attribute to get the URI. So even if we could use the native ITS attribute we want to set the reference in ref. Having the pointer attribute would allow both ITS and XLIFF processors to use the same attribute.

In other words, if we don't have locQualityIssuesRefPointer we would have to do this:

<mrk id='1' type='its:LQI' ref="#idOfStandoffElement" its:locQualityIssuesRef="#idOfStandoffElement">abc</mrk>

If we have a locQualityIssuesRefPointer that would allow the markup to be this:

<mrk id='1' type='its:LQI' ref="#idOfStandoffElement">abc</mrk>


I believe that is the only pointer XLIFF would need for the data categories that have standoff markup.

For the other data categories, if they have more than one information we can use the native ITS markup, if they have one information we can either use a pointer if one is available, or use the native markup.

The only question mark is the case of Storage Size for which there might be a module coming up. But the deadline for new features proposal is the week after next and we have not seen anything yet.

Cheers,
-yves
Received on Thursday, 8 November 2012 14:46:04 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 June 2013 00:25:03 UTC