[] Re: [Issue-55] XLIFF mapping

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

Thoughts?

Felix

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