Hi all,
> In latest published version of the specification document
> I modified the general processing expectations (section 2.1)
> to this:
> • A tool processing a valid XLIFF document that contains XLIFF-defined
> elements that it cannot handle must preserve those elements.
> • A tool processing a valid XLIFF document that contains custom elements
> that it cannot handle should preserve those elements.
> • When a <target> child is added to a <segment> element, the value of
> its xml:space attribute must set to preserve if the xml:space attribute
> of the sibling <source> element is set to preserve.
>
> The change covers one request from David regarding spaces and separates the
> treatment of extensions and XLIFF elements.
>
> This is just a starting point, please propose a new concrete wording
> if you want changes.
I disagree with the proposal for the following reasons:
1) Not all core/module elements should always be preserved when manipulating the document. We need to define this per elements in some cases. Re-segmentation is an obvious example.
2) I assume "XLIFF-defined" means the element is part of a namespace defined by the XLIFF TC. But I don't think this is the same as being a "module". If, for example, part of ITS becomes a module, it's not "XLIFF-defined", but it's still a module.
3) The processing requirements about <target> belongs to the section that defines <target>
So, instead I propose this as general PRs:
-----------
- All user agents MUST follow the processing requirements associated with the core elements and attributes of XLIFF. Those processing requirements are defined throughout the specification.
- A user agent that does not support a given non-core element or attribute SHOULD preserve it, except when a core processing requirement specifies otherwise. (See, for example, section 2.8.3 Segmentation Modification).
-----------
I'm also going to post an email with a initial proposal for the PRs associated with re-segmentation.
Regards,
-yves
