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

[] Re: [Issue-55] XLIFF mapping

From: Felix Sasaki <fsasaki@w3.org>
Date: Thu, 8 Nov 2012 16:38:51 +0100
Message-ID: <CAL58czo-diQ7PwZ1H77BHdLdmCxaTDoDNWGKc=_aEixH=mTnBw@mail.gmail.com>
To: Yves Savourel <ysavourel@enlaso.com>
Cc: public-multilingualweb-lt@w3.org
Hi Yves, all,

thanks a lot for this. I would propose to close issue-51 (too many global
rules) - not only given the XLIFF timeline, but also other discussions
(e.g. about mtconfidence) I don't think that we will reach consensus within
the next weeks what global rules to drop and what not. I would, however,
propose an action item for each data category owner to come up with "as
realistic as possible" examples to demonstrate the usefulness of global



2012/11/8 Yves Savourel <ysavourel@enlaso.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

Felix Sasaki
DFKI / W3C Fellow
Received on Thursday, 8 November 2012 15:39:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:08:24 UTC