Thanks for explaining, Fredrik Re ph, what I meant was addressed by Yves, i.e. encoding the directionality of the placeholder content (that is not part of the extracted translatable content) rather than its vicinity. I agree this can be handled with data if needed. Now regarding <ec> I understand what you say about decreasing the stack level rather than increasing.. But I think that is the matter of the UAX#9 and not of XLIFF We can of course include an informative warning that this is how the dir should work on <ec> if UAX#9 is to be implemented properly. But we do not say anything about increasing stack level on <pc> or <sc> either, we are just making a normative reference to UAX#9. Everything considered, I believe that the </ec> expressivity should not be hindered in cases when it is isolated and the inline metadata solution should be as consistent as possible, we do allow fs and slr on isolated <ec> after all.. Rgds 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 Fri, Dec 20, 2013 at 2:48 PM, Estreen, Fredrik <
Fredrik.Estreen@lionbridge.com > wrote: Hi David, As far as I remember my reasoning for the current setup was that the base method to specify directionality inline was to use the Unicode control codes. In addition to that I wanted XLIFF to be able to create tagging for the commonly occurring idioms in XML formats including XHTML / HTML5 without complicating the processing for XLIFF tools. In those formats spans of some form can have directionality attached, that can be encoded without control characters using <pc>/<sc>+<ec> for complete spans and as <sc> for the start of an orphaned span. If we were to allow directional control on <ec> it would logically mean the end of an existing span that would cause a direction change. That would be hard to model in a straight forward way together with the Unicode BiDi algorithm. In that algorithm such an operation would normally reduce the stack level (ie level 9 -> level 8 for example). If we wanted to preserve that we would need to start at a higher level then what is usual when beginning the paragraph. Or we would prescribe modeling the end of a span as instead increasing the nesting and therefore increasing the stack level. That is of course technically possible but not intuitive. With control codes it is left up to the extractor / modifier to use the appropriate form. <ph> was not given directionality as I did not find it common that placeholder elements was used to describe directionality of following content. It was either spans or plain control characters, that might have changed since then. In the cases placeholders had directionality it was with respect to the thing they represented not the following text. Regards, Fredrik Estreen From:
xliff@lists.oasis-open.org [mailto:
xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: den 20 december 2013 15:30 To: Dr. David Filip Cc: Yves Savourel;
xliff@lists.oasis-open.org Subject: Re: [xliff] RE: Call for dissent on BIDi solution Re: [xliff] bidi Another question, suggestion, I believe that dir should be allowed on isolated <ec> elements? not only <pc> and <sc> 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 Fri, Dec 20, 2013 at 2:24 PM, Dr. David Filip <
David.Filip@ul.ie > wrote: Yves, working on it, But have a question for the Inline SC I guess Why is dir not allowed on <ph>? I know it does not enclose content, but can be useful nevertheless for Extractor/Merger? 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 Fri, Dec 20, 2013 at 1:10 PM, Yves Savourel <
ysavourel@enlaso.com > wrote: Hi David, all, > We might want to say that our inline spans and pairs > should be interpreted as the isolates rather than the the > embeddings if transformed into plaintext. > So this would be an addition to our Directionality section. Doing edits in the specification is a pain, so maybe, to save some time and efforts, you could post an email with the proposed text, and we can dissent or not on it. Currently the paragraphs about inline content are like this: [[ ... The <pc> and <sc> elements have an OPTIONAL attribute dir with a value ltr or rtl. The default value is inherited from the parent <source>, <target>, or <pc> element, in which the respective element is located. Adding bidirectional information in the text content is done using the Unicode bidirectional control characters [UAX #9]. In addition, the <data> element has an OPTIONAL attribute dir with a value ltr or rtl that is not inherited. The default value is ltr. ]] What would be the new text? Thanks, -yves --------------------------------------------------------------------- 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