OASIS Open Document Format for Office Applications (OpenDocument) TC

Dear TC members, Regina and I discussed a bit offline and we would like to suggest a small high-level semantic suggestion before we start working out the details. She suggested and I am following this idea to accept that there are different semantics on "Empty Cell" within the specification, that we have to define each and explicitly name them: The case when @office:value-type="void" and ISBLANK is returning true From the perspective of formula calculation, a cell is empty, if there is no calculable content (according to the existing ODF formula set). From the XML perspective the cell is empty, if <table:table-cell> has no descendants. (This case is likely never used within the specification). From a user perspective, likely derived from the view on a table on a sheet of paper, the table is empty if there is no content. Which brings us to the follow-up question that Andreas recently raised: What is content? Perhaps it helps to make smaller steps and agree with little by little instead of trying to eat an Elephant. Best regards, Svante

Hi, As far as I am concerned #3 is meaningless, since for the user this just means the cell looks empty (for example it could have a number format that for zero only shows the empth string and so looks empty when it has the value 0). As a spreadsheet user, a cell being empty really just means ISBLANK returns TRUE. #2 is concerned with storage of the spreadsheet in ODF format. I believe that should be the consequence of #1. Andreas On 2020-06-25 12:04 p.m., Svante Schubert wrote: Dear TC members, Regina and I discussed a bit offline and we would like to suggest a small high-level semantic suggestion before we start working out the details. She suggested and I am following this idea to accept that there are different semantics on Empty Cell within the specification, that we have to define each and explicitly name them: The case when @office:value-type= void and ISBLANK is returning true From the perspective of formula calculation, a cell is empty, if there is no calculable content (according to the existing ODF formula set). From the XML perspective the cell is empty, if <table:table-cell> has no descendants. (This case is likely never used within the specification). From a user perspective, likely derived from the view on a table on a sheet of paper, the table is empty if there is no content. Which brings us to the follow-up question that Andreas recently raised: What is content? Perhaps it helps to make smaller steps and agree with little by little instead of trying to eat an Elephant. Best regards, Svante -- Andreas J. Guelzow, PhD FTICA Registrar & Director of Enrolment Services Professor, Mathematical & Computing Sciences Direct: +1 780 479 9290 Toll-Free: +1 866 479 5200 concordia.ab.ca

Hello Andreas, allow me to rephrase your answer before I ask questions to make sure I understand: You say the user semantic perspective an "empty cell" should be equal to the function ISBLANK on the cell is returning TRUE. You say in case of the cell state being an empty cell (ISBLANK=True), the ODF XML element of a table should have no child element descendants If this is the case: Do you desire to 'move' shapes and annotations out of the table cell, or shall for cells with shapes or annotation the type 'void' be used? If the cell is empty (ISBLANK=True) should the XML be an empty XML element <table:table-cell/>? Does it allow XML attributes, such as styles (e.g. background colour)? During one of our last TC calls, you mentioned "multi-pass" of Gnumeric when loading ODS. As far I understood, you desired images & annotations to be moved outside the XML of a cell. Could you explain this to me in more detail? Best regards, Svante Am Do., 25. Juni 2020 um 20:17 Uhr schrieb Andreas J Guelzow < andreas.guelzow@concordia.ab.ca >: Hi, As far as I am concerned #3 is meaningless, since for the user this just means the cell "looks" empty (for example it could have a number format that for zero only shows the empth string and so looks empty when it has the value 0). As a spreadsheet user, a cell being empty really just means ISBLANK returns TRUE. #2 is concerned with storage of the spreadsheet in ODF format. I believe that should be the consequence of #1. Andreas On 2020-06-25 12:04 p.m., Svante Schubert wrote: Dear TC members, Regina and I discussed a bit offline and we would like to suggest a small high-level semantic suggestion before we start working out the details. She suggested and I am following this idea to accept that there are different semantics on "Empty Cell" within the specification, that we have to define each and explicitly name them: The case when @office:value-type="void" and ISBLANK is returning true From the perspective of formula calculation, a cell is empty, if there is no calculable content (according to the existing ODF formula set). From the XML perspective the cell is empty, if <table:table-cell> has no descendants. (This case is likely never used within the specification). From a user perspective, likely derived from the view on a table on a sheet of paper, the table is empty if there is no content. Which brings us to the follow-up question that Andreas recently raised: What is content? Perhaps it helps to make smaller steps and agree with little by little instead of trying to eat an Elephant. Best regards, Svante -- Andreas J. Guelzow, PhD FTICA Registrar & Director of Enrolment Services Professor, Mathematical & Computing Sciences Direct: +1 780 479 9290 Toll-Free: +1 866 479 5200 concordia.ab.ca

Hi, please see below On 2020-06-26 10:06 a.m., Svante Schubert wrote: Hello Andreas, allow me to rephrase your answer before I ask questions to make sure I understand: You say the user semantic perspective an empty cell should be equal to the function ISBLANK on the cell is returning TRUE. yes You say in case of the cell state being an empty cell (ISBLANK=True), the ODF XML element of a table should have no child element descendants No, I am not saying that. The XML has to be able to uniquely reflect the fact that the cell is empty, but it does not matter whether the table:table-cell element is empty or not. If this is the case: Do you desire to 'move' shapes and annotations out of the table cell, or shall for cells with shapes or annotation the type 'void' be used? If the cell is empty (ISBLANK=True) should the XML be an empty XML element <table:table-cell/>? Does it allow XML attributes, such as styles (e.g. background colour)? During one of our last TC calls, you mentioned multi-pass of Gnumeric when loading ODS. As far I understood, you desired images & annotations to be moved outside the XML of a cell. Could you explain this to me in more detail? I do not suggest to move images & annotations outside the XML of a cell. It seems that you and other members of the TC are thinking of the xml stream as the document. I consider the document and the xml stream to be distinct (but of course related) objects. The xml stream describes the object. When we read the xml stream, we create a document (which once it is created is independent from teh XML). When we write the document we create a new xml stream. Andreas -- Andreas J. Guelzow, PhD FTICA Registrar & Director of Enrolment Services Professor, Mathematical & Computing Sciences Direct: +1 780 479 9290 Toll-Free: +1 866 479 5200 concordia.ab.ca

I fully agree with you on all your comments. Let us continue the discussion from here. Regina and I discussed offlist the empty cell topic coming to the following insights: I agree now with Regina's idea to make "void" the default value of @office:value-type making the "empty" the default cell state. Therefore we should remove: " The value type of each of these elements shall be specified. " Being the first sentence of the third paragraph of https://docs.oasis-open.org/office/OpenDocument/v1.3/cs01/part3-schema/OpenDocument-v1.3-cs01-part3-schema.html#attribute-office_value-type As the "shall" indicates the mandatory existence of office:value-type, which is not the case in our XML schema: https://tdf.github.io/odftoolkit/docs/odf1.3/OpenDocument-v1.3-cs01-schema-rng.html#15838 If a cell should not have the type "void" there has to be a type attribute. The value of the cell is defined by its value attribute or in case of type string and the absence of the value attribute by the "text content" of a cell. The "text content" should be implicitly defined by defining it once for all XML elements not explicitly for <table:table-cell>. We might want to rename chapter 6 "Paragraph Elements Content" to "Text Content". Paragraph Elements here are <text:p> and <text:h>. The "text content" of a cell is in basically the concatenated "text value" of all traversed <text:p> or <text:h> found as descendants (detailed proposal later). Best regards, Svante Am Fr., 26. Juni 2020 um 18:18 Uhr schrieb Andreas J Guelzow < andreas.guelzow@concordia.ab.ca >: Hi, please see below On 2020-06-26 10:06 a.m., Svante Schubert wrote: Hello Andreas, allow me to rephrase your answer before I ask questions to make sure I understand: You say the user semantic perspective an "empty cell" should be equal to the function ISBLANK on the cell is returning TRUE. yes You say in case of the cell state being an empty cell (ISBLANK=True), the ODF XML element of a table should have no child element descendants No, I am not saying that. The XML has to be able to uniquely reflect the fact that the cell is empty, but it does not matter whether the table:table-cell element is empty or not. If this is the case: Do you desire to 'move' shapes and annotations out of the table cell, or shall for cells with shapes or annotation the type 'void' be used? If the cell is empty (ISBLANK=True) should the XML be an empty XML element <table:table-cell/>? Does it allow XML attributes, such as styles (e.g. background colour)? During one of our last TC calls, you mentioned "multi-pass" of Gnumeric when loading ODS. As far I understood, you desired images & annotations to be moved outside the XML of a cell. Could you explain this to me in more detail? I do not suggest to move images & annotations outside the XML of a cell. It seems that you and other members of the TC are thinking of the xml stream as the document. I consider the document and the xml stream to be distinct (but of course related) objects. The xml stream describes the object. When we read the xml stream, we create a document (which once it is created is independent from teh XML). When we write the document we create a new xml stream. Andreas -- Andreas J. Guelzow, PhD FTICA Registrar & Director of Enrolment Services Professor, Mathematical & Computing Sciences Direct: +1 780 479 9290 Toll-Free: +1 866 479 5200 concordia.ab.ca

Wording correction: The "text content" of a cell is in basically the concatenated "text value " of all traversed <text:p> or <text:h> found as descendants (detailed proposal later). The "text content" of a cell is in basically the concatenated "text content " of all traversed <text:p> or <text:h> found as descendants (detailed proposal later). According to Chapter 6.1 Basic Text Content: https://docs.oasis-open.org/office/OpenDocument/v1.3/cs01/part3-schema/OpenDocument-v1.3-cs01-part3-schema.html#__RefHeading__1415194_253892949