RE: [xliff] Source read only or modifiable?

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo, all,

>> 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).
>
> If xml:space is not set to "preserve", then spaces are meaningless
> from XML point of view and normalization does not affect content.
> That's something defined in a level above XLIFF. 
 
Good. So normalizing source (if xml:preserve != 'preserve') would not be a modification of the content.



>>> Annotations using <mrk> alter source text.
>> 
>> No more than <segment> elements.
>
> An annotation does not represent anything included in the original
> document. It is neither original text nor formatting information 
> that needs to be preserved.

Exactly. So we agree that adding/removing annotations does not modify 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.
>
> If that's not part of the original content to merge, then 
> it is not an essential inline element.

Exactly. It can be ignored by the merger tool.


 
>> 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.
>
> If it is not generated by the extraction tool, then it
> should not be in core. It must live in an optional module.

The SC hasn't discussed yet if the different elements of the inline markup should be part of the core or their own namespace(s). So I don't have an opinion on this yet.

Note that annotations can be generated by the extraction tool, and some can be important to the translation process (e.g. <mrk translate='no'>). So there might be a case for <mrk> to be part of the core if the other inline elements are.

I hope the SC will be able to address that question during the face-to-face meeting.



>>> 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.
>
> Then the tool creating the XLIFF file should be able to 
> indicate whether those additions are acceptable or not. 
> This can be indicated with an attribute at <file> level. The 
> original tool should have a way to express that <target> must 
> have the same structure as the original <source> (that should 
> be the default case IMO). It also should be able to express 
> that alterations to <source> are not allowed. And, for 
> completeness sake, it should be able to indicate whether 
> re-segmentation is allowed.

I agree that being able to set different permissions at the file level may be useful.
Permission for adding/removing inline codes can be set at the code level, but a file-level flag could complement (or override that).
Permission to re-segment could be useful too.

I think there is an item in the features list:
(http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/PermissionControl)
That may be related to this.


Cheers,
-yves