[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Call for dissent: csprd02 101, add requirement to preserve XLIFF-defined attributes (along with elements) and remove fs from <cp>
Per the two observations Yves made in csprd02 101, “fs attributes,” https://lists.oasis-open.org/archives/xliff-comment/201309/msg00014.html
- change the PR from “An Agent processing a valid XLIFF Document that contains XLIFF-defined elements that it cannot handle MUST preserve those elements” to “An Agent processing a valid XLIFF Document that contains XLIFF-defined elements and attributes that it cannot handle MUST preserve those elements and attributes.”
- remove @fs and @subFs form <cp>
I propose we accept both suggestions.
If I do not receive dissent by the end of the week, I will consider this approved.
Subject: csprd02 comment - fs attributes
There is this PR: "An Agent processing a valid XLIFF Document that contains XLIFF-defined elements that it cannot handle MUST
preserve those elements."
I think the wording of the PR does not correspond to the original intent. There is no mention of XLIFF-defined attributes, which
means that, as of csprd02, I'm not required to preserve any of the Format Style attributes.
It is the intent?
I think the intent was to preserve any XLIFF-defined element or attribute.
So assuming the PR is changed, we would have to preserve fs/subFs attributes. This leads to another issue:
The fs/subFs attributes are allowed on pretty much any element of the core, including <cp>. This means a reader would have be able
to preserve the fs/subFs attributes of a <cp> element.
The <cp> element is an escape mechanism, there is no realistic way to preserve fs/subFs on something that will be converted to a
character in the parsed document.
- if the PR is to protect only elements: nothing to change.
- if it is to protect elements and attributes:
- it needs to be update (and the PR for custom namespaces too)
- fs/subFs should be removed from <cp>