RE: [xliff] Source read only or modifiable?

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo, all,

> Normalizing spaces means modifying spaces. 
> It is a change that should not be allowed in 
> any stage if the xml:space attribute is set 
> to “preserve”.

The question was: "Would a content *not* marked with xml:space=’preserve’ be considered modified if it gets normalized?" (in the context of having a "read-only" source).


> Annotations using <mrk> alter source text. 

No more than <segment> elements.
And we said re-segmenting was not considered a modification of the content.


> If the tool that creates the XLIFF doesn’t add
> <mrk> elements, then <mrk> elements should not be
> present when the XLIFF returns to the original 
> tool for generating the translated file.

I disagree. Like with <segment>, the merging tool can strip the <mrk>. By definition they are not part of the content to merge.

This is how <mrk> is defined in 1.2 ("The <mrk> element is usually not generated by the extraction tool and it is not part of the tags used to merge the XLIFF file back into its original format.") and I certainly hope that the same principle will carry over in 2.0.


> As we discussed the other day during the meeting, 
> changes done by a second tool should be temporary and 
> the original <source> restored before moving to the 
> next tool/stage.

We discussed this when talking about inline codes (e.g. converting text to inline codes, i.e. adding codes). We were not talking about <mrk> at that time.


> I proposed a solution for annotations some time ago 
> that used offsets stored as attributes in an element 
> outside <source> or <target>. Annotations don’t need 
> to alter the original source. They don’t need to be 
> inline elements at all, they can be optional elements 
> that live in a module.

Your idea was discussed in the Inline Markup SC and unanimously found impractical for an XML exchange format.

If XLIFF was a binary format in the other hands... But it's not.


> There should not be any extra element added 
> during the translation process. Neither in <source> 
> nor in <target>.

I disagree. We must be able to add/remove inline codes in the target.
It's a basic requirement.


Cheers,
-yves