Re: ITS rules in XLIFF

That makes sense. I think it's good to keep anything ID-like off of the
<source> element, too, since it might end up getting copied and renamed as
<target>, which could lead to a duplicate ID. The XLIFF standard seems to
agree,  only allowing for an id value on <trans-unit>. For a part of WICS
we wondered if we needed to parse documents invalidated by a duplicate
xml:id value.
Nathan


On Tue, Oct 1, 2013 at 12:07 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

> > The other category that has the same source/
> > target confusion problem is idValue, which is
> > currently mapped to resname on trans-unit.
>
> For that one I think maybe it's a case of non-mapping.
>
> We use idValue to link the content in the source document and the XLIFF
> document. In the vast majority of the case, the source text is replaced by
> the target text, so they have the same ID, and it make sense to use resname
> for this in XLIFF.
>
> For the cases where the translation goes to a different node which has
> also an ID, as in your case, maybe it make sense to say that the idValue
> mapping applies only to source content ID because you are still likely to
> be able to use targetPointer to merge back the translation at the right
> node.
>
> The important part is to be able to identify the couple source/target by
> an ID that is unlikely to change. I would say that even if the id of the
> source is not the id of the target, it still provides a unique way of
> identifying the pair.
>
> Cheers,
> -yves
>
>