OASIS Open Document Format for Office Applications (OpenDocument) TC

Greetings! Francis Cave spotted a possible issue with foreign elements under 3.17, which reads in part: ***** If a foreign element has a <text:h> or <text:p> ancestor element, and is a child element of an element for which the OpenDocument schema permits the inclusion of character data, and if the OpenDocument schema permits the inclusion of character data for all *its* ancestors up to the <text:p> or <text:h> element ancestor element, or a <text:ruby-base> ancestor element, ***** Francis asks: ***** I don't understand the condition ...and if the OpenDocument schema permits the inclusion of character data for all its ancestors up to... . What does its refer to in this context? I presume it refers to of an element earlier in the sentence. If that is the case, surely it is sufficient that the parent element of the foreign element permits the inclusion of character data. ***** I see two different cases and don't know which one is correct. First case: <text:p> / other ancestors / <parent:element> (allows character data) / <foreign:element> (content) </foreign:element> If Francis is correct, then the <parent:element> allowing character data is sufficient. Second case, which I include because we used for all of its ancestors : <text:p> / other ancestors *all of which must allow character data / <parent:element> (allows character data) / <foreign:element> (content) </foreign:element> Those are two very distinct cases and I lean towards the second based on the current text but: 1) Was that intentional? 2) Does it make any difference in how implementations manage foreign elements? Since Francis and I are trying to push out the next drafts, I will be asking the TC to take up this question first at our Monday meeting. Hope everyone is having a great weekend! Patrick -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Attachment: signature.asc Description: OpenPGP digital signature

On 24.11.18 16:43, Patrick Durusau wrote: Greetings! Francis Cave spotted a possible issue with foreign elements under 3.17, which reads in part: ***** If a foreign element has a <text:h> or <text:p> ancestor element, and is a child element of an element for which the OpenDocument schema permits the inclusion of character data, and if the OpenDocument schema permits the inclusion of character data for all *its* ancestors up to the <text:p> or <text:h> element ancestor element, or a <text:ruby-base> ancestor element, ***** Francis asks: ***** I don't understand the condition ...and if the OpenDocument schema permits the inclusion of character data for all its ancestors up to... . What does its refer to in this context? I presume it refers to of an element earlier in the sentence. If that is the case, surely it is sufficient that the parent element of the foreign element permits the inclusion of character data. ***** its refers to: of an element for which the OpenDocument schema permits the inclusion of character data maybe it would be clearer if it said of an element E ... and replace its with element E's ? I see two different cases and don't know which one is correct. First case: <text:p> / other ancestors / <parent:element> (allows character data) / <foreign:element> (content) </foreign:element> If Francis is correct, then the <parent:element> allowing character data is sufficient. Second case, which I include because we used for all of its ancestors : <text:p> / other ancestors *all of which must allow character data / <parent:element> (allows character data) / <foreign:element> (content) </foreign:element> Those are two very distinct cases and I lean towards the second based on the current text but: 1) Was that intentional? yes - the intent of this paragraph in 3.17 is that the character content inside of foreign elements that are in a location in the tree that ends up as text in a paragraph may be imported as such, while in other locations it's ... well not disallowed since we say should not , but discouraged. for example if we have: <text:p><text:span><foo>blah</foo></text:span></text:p> the blah may simply become the content of the text:span element and thus the paragraph. <text:p><draw:frame><foo>blah</foo></draw:frame></text:p> the blah is not allowed to become content of the paragraph because it's inside draw:frame which does not permit character data. 2) Does it make any difference in how implementations manage foreign elements? ... likely? regards, michael -- Michael Stahl Senior Software-Entwickler LibreOffice CIB software GmbH GeschÃftsstelle Hamburg Flachsland 10 22083 Hamburg T +49 (40) / 28 48 42 -296 F +49 (40) / 28 48 42 -100 Michael.Stahl@cib.de www.cib.de Sitz: MÃnchen Registergericht MÃnchen, HRB 123286 GeschÃftsfÃhrer: Dipl.-Ing. Ulrich Brandner

On 26.11.18 11:29, Michael Stahl wrote: yes - the intent of this paragraph in 3.17 is that the character content inside of foreign elements that are in a location in the tree that ends up as text in a paragraph may be imported as such, while in other locations it's ... well not disallowed since we say "should not", but discouraged. for example if we have: <text:p><text:span><foo>blah</foo></text:span></text:p> the "blah" may simply become the content of the text:span element and thus the paragraph. <text:p><draw:frame><foo>blah</foo></draw:frame></text:p> the "blah" is not allowed to become content of the paragraph because it's inside draw:frame which does not permit character data. sorry, this is a better example: <text:p><draw:frame><svg:desc><foo>blah</foo></svg:desc></draw:frame></text:p> here, svg:desc allows character data, but draw:frame does not. -- Michael Stahl Senior Software-Entwickler LibreOffice CIB software GmbH GeschÃftsstelle Hamburg Flachsland 10 22083 Hamburg T +49 (40) / 28 48 42 -296 F +49 (40) / 28 48 42 -100 Michael.Stahl@cib.de www.cib.de Sitz: MÃnchen Registergericht MÃnchen, HRB 123286 GeschÃftsfÃhrer: Dipl.-Ing. Ulrich Brandner