RE: [xliff] Source read only or modifiable?

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel
> Sent: Wednesday, May 23, 2012 1:00 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Source read only or modifiable?

Hi,

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

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


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

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

We did not mention element names but we talked about elements added to <source> and <mrk> is an element.
 
> 
> > 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.

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.
 
Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com