OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
Back to discussions
Expand all | Collapse all

Call for dissent: csprd02 101, add requirement to preserve XLIFF-defined attributes (along with elements) and remove fs from

  • 1.  Call for dissent: csprd02 101, add requirement to preserve XLIFF-defined attributes (along with elements) and remove fs from

    Posted 11-12-2013 23:28
    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.”   And   - 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.   Thanks,   Bryan   Subject : csprd02 comment - fs attributes From : "Yves Savourel" <yves@opentag.com> To : <xliff-comment@lists.oasis-open.org> Date : Mon, 23 Sep 2013 10:42:24 -0600 Hi all,   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>   Regards, -yves        


  • 2.  Re: [xliff] Call for dissent: csprd02 101, add requirement to preserve XLIFF-defined attributes (along with elements) and remove fs from

    Posted 11-14-2013 14:10
    Sounds good to me dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Tue, Nov 12, 2013 at 11:27 PM, Schnabel, Bryan S < bryan.s.schnabel@tektronix.com > wrote: 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.”   And   - 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.   Thanks,   Bryan   Subject : csprd02 comment - fs attributes From : "Yves Savourel" < yves@opentag.com > To : < xliff-comment@lists.oasis-open.org > Date : Mon, 23 Sep 2013 10:42:24 -0600 Hi all,   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>   Regards, -yves        


Related Content