OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]