OASIS XML Localisation Interchange File Format (XLIFF) TC

Thanks, Yves,  we had not managed to resolve this formally before we lost quorum. However, everyone seemed OK with the following: 1) Introduce the third value "auto" in our markup solution for directionality and make "auto" the default. "auto" sets directionality heuristically, i.e. based on the first strongly directional character within its scope 2) drop the dir attributes from <source> and <target>, so that trgDir and srcDir is inherited directly from <unit> This will make re-segmentation PR simpler and will less likely lead to usage of directional controls. 3) Inline the agents will be required to have full UAX#9 support [we alreadu have UAX#9 as a normative reference, we just update to the 6.3 edition with the isolates] That is we do not prohibit using any legal characters including the directionality controls We might add some best prectice examples for Extractors that would ideally prevent usage of the control characters. Note that 2) above will make usage of directionality controls less likely, becuase extractors will likely use inline dirs to govern sub-unit flows I will consider this approved by consensus, unless I hear dissent by the end of this week Best regards 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, Dec 17, 2013 at 5:42 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi Fredrik, David, all, Sorry I had to leave at the top of the hour. I don't know what was decided, but removing dir from source/target may be quite helpful at the implementation level as it become a lot easier to get inherit directly from the unit. So I wouldn't see any problem going in that direction. That doesn't answer the basic issue of directionality at the inline-level (values for <pc>/<sc>, using control chars or not, etc.) but it eliminates the question from the segmentation modification. BTW: should <ec> have dir too? (when isolated) Cheers, -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

> 1) Introduce the third value "auto" in our markup solution > for directionality and make "auto" the default. > "auto" sets directionality heuristically, i.e. based on > the first strongly directional character within its scope OK. > 2) drop the dir attributes from <source> and <target>, so that > trgDir and srcDir is inherited directly from <unit> > This will make re-segmentation PR simpler and will less > likely lead to usage of directional controls. OK. > 3) Inline the agents will be required to have full UAX#9 support > [we alreadu have UAX#9 as a normative reference, we just update > to the 6.3 edition with the isolates] > That is we do not prohibit using any legal characters including > the directionality controls I don't know what "the agents will be required to have full UAX#9 support" means but I guess we don't have to change any text as the current one already mentions UAX#9. OK for the current text mentioning UAX#9 and updating the UAX#9 reference. Cheers, -yves

On Thu, Dec 19, 2013 at 12:43 AM, Yves Savourel < ysavourel@enlaso.com > wrote: > 3) Inline the agents will be required to have full UAX#9 support > [we alreadu have UAX#9 as a normative reference, we just update > to the 6.3 edition with the isolates] > That is we do not prohibit using any legal characters including > the directionality controls I don't know what "the agents will be required to have full UAX#9 support" means but I guess we don't have to change any text as the current one already mentions UAX#9. OK for the current text mentioning UAX#9 and updating the UAX#9 reference. Thanks Yves, this is basically what I meant. In particular. The UAX#9 in the 6.3 has the new isolate control characters. Anyway supprting BiDi in general means supporting UAX#9, we are just making a normative reference to it. What we do is providing a provision for the "higher level protocols" as mentioned in UAX#9 AND mappings for our inline elements. Here is maybe some space for clarification: While the higher level does not need any mapping because it is simply a way to determine the baseline direction of the paragraph. 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. 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

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

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

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

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    

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    

> Yves, working on it, Good, thanks. BTW: I recall Fredrik noting that isolated markers for bidi had the issue of not working well when the first characters of their content was weak, so I don't know if we should recommend anything other than "look at AUX#9". Since we won't have dir on segments we don't have to do any conversion between markup and control characters normally. > 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? Since <ph> is always empty there is no content to apply the dir attribute. You have a dir attribute on <data> if you want to apply such info to the content of a <ph>. Cheers, -ys

On Fri, Dec 20, 2013 at 2:40 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Since <ph> is always empty there is no content to apply the dir attribute. You have a dir attribute on <data> if you want to apply such info to the content of a <ph>. That's what I suspected, wanted to double-check anyway, thanks 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

Yves I did the previously agreed groundwork  1) Introducing the value "auto" as the third and default value. 2) Removing dir from source and target I also tentatively introduced dir on isolated <ec>s This will be visible in the next print out As result the section on Bidirectional text needs more changes Previous text: Text directionality in XLIFF content is defined by inheritance. Source and target content can have different directionality. The initial directionality for both the source and the target content is defined in the <file> element, using the optional attributes srcDir for the source and trgDir for the target. The default value for both attributes is ltr. The <group> and <unit> elements also have the two optional attributes srcDir and trgDir. Their values must be either ltr or rtl. The default value of the srcDir is inherited from the value of the srcDir attribute of the respective parent element. The default value of the trgDir attribute is inherited from the value of the trgDir attribute of the respective parent element. The <source> element has an optional attribute dir with a value ltr or rtl. The default value is the same as the value of the of the srcDir attribute on the <unit> element, in which the element is located. The <target> element has an optional attribute dir with a value ltr or rtl. The default value is the same as the value of the trgDir attribute of the <unit>, in which the element is located. 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. New text: Text directionality in XLIFF content is defined by inheritance. Source and target content can have different directionality. The initial directionality for both the source and the target content is defined in the <file> element, using the optional attributes srcDir for the source and trgDir for the target. The default value for both attributes is auto. The <group> and <unit> elements also have the two optional attributes srcDir and trgDir. The default value of the srcDir is inherited from the value of the srcDir attribute of the respective parent element. The default value of the trgDir attribute is inherited from the value of the trgDir attribute of the respective parent element. The <pc>, <sc>, and isolated <ec> elements have an optional attribute dir with a value ltr, rtl, or auto. The default value is inherited from the parent <pc> element. In case the inline element is a child of a <source> element, the srcDir attribute value will be inherited from the enclosing <unit> element, whereas the trgDir attribute value will be inherited in case the inline element is a child of a <target> element. Warning:  While processing isolated <ec> elements with explicitly set directionality, please beware that unlike directionality set on the <pc> and <sc> , this method decreases the stack level as per [UAX #9]. In addition, the <data> element has an optional attribute dir with a value ltr, rtl, or auto that is not inherited. The default value is auto. Directionality of source and target text contained in the <source> and <target> elements is fully governed by [UAX #9], whereas explicit XLIFF-defined structural and directionality markup is a higher-level protocol in the sense of [UAX #9]. The XLIFF-defined value auto determines the directionality based on the first strong directional character in its scope and XLIFF-defined inline directionality markup behaves exactly as Explicit Directional Isolate Characters, see [UAX #9], http://www.unicode.org/reports/tr9/#Directional_Formatting_Characters . Note: Please note that this specification does not define explicit markup for inline directional Overrides or Embeddings; in case those are needed. Extractors and Modifiers will need to use [UAX #9] defined Directional Formatting Charcters. 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

Thanks David, One suggestion, to change this: [[ The <pc>, <sc>, and isolated <ec> elements have an optional attribute dir with a value ltr, rtl, or auto. The default value is inherited from the parent <pc> element. In case the inline element is a child of a <source> element, the srcDir attribute value will be inherited from the enclosing <unit> element, whereas the trgDir attribute value will be inherited in case the inline element is a child of a <target> element. ]] To this: [[ The <pc>, <sc>, and isolated <ec> elements have an optional attribute dir with a value ltr, rtl, or auto. The default value is inherited from the parent <pc> element. In case the inline element is a child of a <source> element, the default value is inherited from the srcDir value of the parent <unit> element. In case the inline element is a child of a <target> element, the default value is inherited from the trgDir value of the parent <unit> element. ]] I don't have a strong opinion on the rest of the text as I'm no bidi expert. But I really hope some bidi expert will look at it and make sure it makes sense. In general I feel that the least we say on that topic, the better. Cheers, -yves

Thanks, Yves, it is indeed awkward describing the grand-child inheritance, I thought my wording was fine, nevertheless The <pc>, <sc>, and isolated <ec> elements have an optional attribute dir with a value ltr, rtl, or auto. The default value is inherited from the parent <pc> element. In case the inline element is a child of a <source> element, the default value is inherited from the srcDir value of the enclosing  <unit> element. In case the inline element is a child of a <target> element, the default value is inherited from the trgDir value of the enclosing  parent <unit> element. Please note that this section is just a summary of normative provisions elsewehere in the spec (on the elements and attributes in question) except for the normative reference to UAX# and the mapping of XLIFF to UAX#9 provisions Notably the dir attribute description dir Directionality - indicates the directionality of content. Value description: ltr (Left-To-Right), rtl (Right-To-Left), or auto (determined heuristically, based on the first strong directional character in scope, see [UAX #9]). Default value: default values for this attribute depend on the element in which it is used: When used in a <pc>, <sc>, or <ec> element that has a <source> element as its parent: The value of the srcDir attribute of the <unit> element, in which the elements are located. When used in a <pc>, <sc>, or <ec> element that has a <target> element as its parent:  The value of the trgDir attribute of the <unit> element, in which the elements are located. When used in a <pc>, <sc>, or <ec> element that has a <pc> element as its parent: The value of the dir attribute of the parent <pc> element. When used in <data>: The value auto. Used in: <data>, <pc>, <sc>, and <ec>. I agree that we should say as little as possible, and I think that the proposed section says just the necessary bare minimum. Review by a BiDi expert obviously most welcome I am going to commit this resulting version, and happy to implement improvements if these are suggested by the next meeting Best regards 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 Sun, Dec 22, 2013 at 5:01 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Thanks David, One suggestion, to change this: [[ The <pc>, <sc>, and isolated <ec> elements have an optional attribute dir with a value ltr, rtl, or auto. The default value is inherited from the parent <pc> element. In case the inline element is a child of a <source> element, the srcDir attribute value will be inherited from the enclosing <unit> element, whereas the trgDir attribute value will be inherited in case the inline element is a child of a <target> element. ]] To this: [[ The <pc>, <sc>, and isolated <ec> elements have an optional attribute dir with a value ltr, rtl, or auto. The default value is inherited from the parent <pc> element. In case the inline element is a child of a <source> element, the default value is inherited from the srcDir value of the parent <unit> element. In case the inline element is a child of a <target> element, the default value is inherited from the trgDir value of the parent <unit> element. ]] I don't have a strong opinion on the rest of the text as I'm no bidi expert. But I really hope some bidi expert will look at it and make sure it makes sense. In general I feel that the least we say on that topic, the better. Cheers, -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