[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-comment] Resolution for the public review comments on "Processing Requirements for XML PIs"
Hi Bryan, > Regarding your public review comment, csprd01 15 > Processing Requirements for XML PIs, I implemented > the result prescribed by the TC ballot > ... > And noted that XML Processing Requirements within a > segment could cause ambiguity upon re-segmentation > and may be removed on output. Thanks for working on that item. While comment 15 is from Jörg, comment 13 is from me and is also related to processing instructions. == a) First, a short note: could you point me to the latest copy of the HTML or PDF version of the editor's draft? I do see your changes (rev 269 and 268) about PIs in the log: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/?op=log&rev=0&sc=0&isdir=1 but none of the HTML or PDF files in SVN seem to have those changes. The file xliff-core.pdf listed as Editor's draft in the wiki (https://wiki.oasis-open.org/xliff/) seems to be still at revision 267 for now. == b) As far as the resolution. From the log diffs (so I can't be sure I'm not missing something) I have two comments: - In the new section there is a note that says: "Note: Using Processing Instructions as a means to implement a feature already specified in XLIFF core or modules is prohibited. Doing so constitutes noncompliance." While the wording is clear, it may help to have the text with a MUST or MUST NOT and be listed in the PRs items for that section, so it becomes part of the conformance clauses. Basically the same as the PR in the section about extension. - There is no provision that address the 3 comments of the ballot that indicates PIs should not be allowed inside source and target content. Note that 2.0 does not allow extensions there currently. - I believe you meant "XML Processing Instructions" not "XML Processing Requirements" in the text "XML Processing Requirements within a segment could cause ambiguity upon re-segmentation and <glossterm>may</glossterm> be removed on output." Cheers, -yves