RE: [xliff] Source read-only or not?

[Yves Savourel <ysavourel@enlaso.com>]

> Why put a restriction for converting codes to <ph>
> if we are allowing changes? As it would be allowed
> to add inline codes, removing existing ones should
> also be allowed, then replacing <pc> or <sc>/<ec>
> with <ph> would be possible.

Good point: I suppose some step may want to re-do the whole inline code tagging if they want to.



> Considering that <source> content would be modifiable, 
> we cannot rely on it anymore for generating a partially
> translated document from an incomplete XLIFF that lacks
> some <target> elements.

Not sure why.



> If annotations end inside <source> instead of staying 
> outside using attributes to indicate start and end, 
> I would make them completely ignorable, treating them 
> in the same way XML comments are treated.
> Anything that doesn't have origin in the source document
> and is not required for generating a translated 
> document should be ignorable. 

That's why I said: annotations can be delete.

But I wouldn't treat a marker and a comment (or a PI) the same way.

a) The comment (or the PI) is not an XLIFF data structure. It interferes with the content. It must not be present in the parsed content. It MAY be preserved if the tool wants to do so (but making sure it does not interfere with the content). 

b) The annotation is a valid XLIFF structure carrying interoperable information. It does not interfere with the content as we have processing expectations associated with it. One of which should be to ignore annotations when you have a need to see the content with just text and inline codes. The annotation SHOULD be preserved on output.

In summary: comments/PIs MAY be preserved, annotations SHOULD be preserved, neither MUST be preserved.

And the Inline Markup SC has still to resolve the case of translate and possibly direction information: Currently it's not completely clear yet how to represent such information if it was in the original document (as an annotation, or an inline code, or both).



>> ...But then xml:space would apply to all child 
>> elements (not just <source> and <target>.
>
> Having the "xml:space" attribute at <unit> level will 
> affect matches coming from TM that may need to be 
> preserved as retrieved. That seems a bad idea.

Exactly.

But then we need to make sure an xml:space set in the <source> gets copied over to <target> if the target element didn't exist. I don't think we have a processing expectation stating this explicitly. So technically one could have a <source xml:space='preserve'> and a <target>.

Cheers,
-yves