OK, if no one objects, I would be happy with the PR solution MAY delete or change to "yes" 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 Thu, Nov 21, 2013 at 1:03 AM, Yves Savourel <
ysavourel@enlaso.com > wrote: Hi David, Both a note and a PR to indicate the change MAY be made would be fine. -ys From: Dr. David Filip [mailto:
David.Filip@ul.ie ] Sent: Wednesday, November 20, 2013 9:39 AM To: Yves Savourel Cc:
xliff@lists.oasis-open.org Subject: Re: [xliff] Re-ordering of inline codes Yves, I can see that this has very small impact in fact. Nevertheless, it is confusing things. It allows to define a sequence of one (which is a theroretical nonsense) that has effectively the same semantic as canReoder="yes", which is much worse than just being theoretically wrong or ugly. This said I am not against IFF we add a note explaining that sequence of one was allowed to simplify extraction and has actually no impact. Alternatively, we could normatively allow Modifiers (add a PR) to clean up and kill sequences of one, replacing isolated "fisrtNo" with "yes" or deleting it since "yes" is the default I suppose.. Cheers 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 Wed, Nov 20, 2013 at 3:51 PM, Yves Savourel <
ysavourel@enlaso.com > wrote: Hi all, I've implemented the changes for the canReorder attribute and identify a possible small change that would make things a lot easier for both extraction and validation: Currently we define a "sequence" as this: [[ Inline codes re-ordering within a source or target content can be limited by defining no-reordereable sequences. Such sequence is made of two or more consecutive inline elements where the first element has canReorder set to firstNo and the next elements have canReorder set to no. ]] When extracting you may know that an inline code should not be reordered but based on our definition you should mark it so only if there are two or more of them. This forces the extractor to do some look-ahead or back-writing. Allowing sequence made of a single element would simplify things. Obviously such sequences would be moot, but they wouldn't hamper anything either. So I would propose to amend the text above to: [[ Inline codes re-ordering within a source or target content can be limited by defining no-reorderable sequences. Such sequence is made of a first inline element with canReorder set to firstNo and zero or more consecutive elements with canReorder set to no. ]] Cheers, -ys --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php