OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Agenda for August 15th ODF TC Teleconference meeting

    Posted 08-10-2022 20:19
    Greetings! A draft agenda for our TC call on Monday, 2022-08-15 Time of meeting: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022&month=8&day=15&hour=16&min=0&sec=0&p1=25&p2=37 The call counts towards voter eligibility. Teleconference Numbers - Access code: 438387 Canada - (use US number) Denmark - +45 78 77 25 34 Germany - +49 30 255550324 Hungary - +36 1 987 6874 The Netherlands - +31 6 35205016 United Kingdom - 44 330 777 2407 US (267) 807-9605 Chat room for meeting is at http://webconf.soaphub.org/conf/room/odf < http://webconf.soaphub.org/conf/room/odf > Please send comments to the mailing list. 1. Dial-In, Roll Call, Determination of Quorum and Voting Rights 2. Motion (simple majority): Approve the Agenda 3. Motion (simple majority): Approve minutes of 08 August 2022 https://lists.oasis-open.org/archives/office/202208/msg00001.html While I agree with Michael Stahl that Office-4024 isn't ready or easy to resolve, it maybe a serious error in our conformance clauses that really needs to be addressed before ODF 1.4 progresses. I welcome any and all suggestions, rejoinders, proposals that anyone cares to contribute. It's entirely possible that I may venture some text as a starting point either later today or early tomorrow. 4. Office-4024 - https://issues.oasis-open.org/browse/OFFICE-4024 5. Adjournment. -- 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: OpenPGP_signature Description: OpenPGP digital signature


  • 2.  Re: [office] Agenda for August 15th ODF TC Teleconference meeting

    Posted 08-11-2022 00:16
    Hi Patrick, Patrick Durusau schrieb am 10.08.2022 um 22:19: [..] I welcome any and all suggestions, rejoinders, proposals that anyone cares to contribute. It's entirely possible that I may venture some text as a starting point either later today or early tomorrow. So here is my proposal: (A) Add the following sentence to 19.811 text:formula: If a namespace prefix is not specified, the namespace defaults to the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace. The specification of 19.600 table:condition, 19.600 table:condition, 19.639 table:expression and 19.646 table:formula already contains such a sentence. Under the proposed addition for 19.811 text:formula, all affected attribute descriptions specify which namespace to use when a prefix is missing. Therefore, this can be omitted in item D.3). (B) My proposal for item D.3) in 2.2.1 OpenDocument Document: The specification of style:condition (19.472), table:condition (19.600), table:expression (19.639), table:formula (19.646) and text:formula (19.811) determines a namespace to be used for the attribute value. This namespace determines the syntax and semantics of formulas or expressions in the attribute value. If the namespace to be used is the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace, then the formulas and expressions shall conform to Part 4 of this specification. (C) Add in each of the five attribute descriptions: Producer should only use the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace to ensure interoperability. Kind regards Regina


  • 3.  Re: [office] Agenda for August 15th ODF TC Teleconference meeting

    Posted 08-12-2022 21:04
    Regina, Thanks! Comments below: On 8/10/22 20:15, Regina Henschel wrote: Hi Patrick, Patrick Durusau schrieb am 10.08.2022 um 22:19: [..] I welcome any and all suggestions, rejoinders, proposals that anyone cares to contribute. It's entirely possible that I may venture some text as a starting point either later today or early tomorrow. So here is my proposal: (A) Add the following sentence to 19.811 text:formula: If a namespace prefix is not specified, the namespace defaults to the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace. OK. The specification of 19.600 table:condition, 19.600 table:condition, 19.639 table:expression and 19.646 table:formula already contains such a sentence. Under the proposed addition for 19.811 text:formula, all affected attribute descriptions specify which namespace to use when a prefix is missing. Therefore, this can be omitted in item D.3). Not 19.600 table:condition twice, yes? (B) My proposal for item D.3) in 2.2.1 OpenDocument Document: The specification of style:condition (19.472), table:condition (19.600), table:expression (19.639), table:formula (19.646) and text:formula (19.811) determines a namespace to be used for the attribute value. This namespace determines the syntax and semantics of formulas or expressions in the attribute value. If the namespace to be used is the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace, then the formulas and expressions shall conform to Part 4 of this specification. But doesn't setting style:condition (19.472) to Part 4 change the meaning of: style:condition="odf:footnote()" Because the condition footnote() isn't defined in Part 4? And none of the other conditions are so defined. ***** Not to mention that doesn't address our changing from "shall" support Part 4 (which was an error for style:condition) to some namespace with a default. Thinking perhaps, not committed to this, that we should: 1) To Andreas' point, keep shall either use our namespace or default to it, but 2) May support other namespaces but that's not required for conformance, good for interoperability but allows conformance to remain as it is now. (C) Add in each of the five attribute descriptions: Producer should only use the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace to ensure interoperability. Producers .... yes? Hope everyone has a great weekend! Patrick Kind regards Regina -- 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: OpenPGP_signature Description: OpenPGP digital signature


  • 4.  Re: [office] Agenda for August 15th ODF TC Teleconference meeting

    Posted 08-13-2022 14:33
    Hi Patrick, Patrick Durusau schrieb am 12.08.2022 um 23:03: Regina, Thanks! Comments below: On 8/10/22 20:15, Regina Henschel wrote: [..] The specification of 19.600 table:condition, 19.600 table:condition, 19.639 table:expression and 19.646 table:formula already contains such a sentence. Under the proposed addition for 19.811 text:formula, all affected attribute descriptions specify which namespace to use when a prefix is missing. Therefore, this can be omitted in item D.3). Not 19.600 table:condition twice, yes? First one should have been 19.472 style:condition. (B) My proposal for item D.3) in 2.2.1 OpenDocument Document: The specification of style:condition (19.472), table:condition (19.600), table:expression (19.639), table:formula (19.646) and text:formula (19.811) determines a namespace to be used for the attribute value. This namespace determines the syntax and semantics of formulas or expressions in the attribute value. If the namespace to be used is the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace, then the formulas and expressions shall conform to Part 4 of this specification. But doesn't setting style:condition (19.472) to Part 4 change the meaning of: style:condition="odf:footnote()" Because the condition footnote() isn't defined in Part 4? Please see in 19.472 style:condition itself, how the namespace is used. There you find "The XML namespace that applies to the style:condition attribute specifies the syntax and semantics of any /expression/ occurrences in the style:condition syntax." The conditions that may be used by paragraph styles do not contain any /expression/. Thus style:condition="of:footnote()" is syntactically correct. But the bounding to _any_ namespace is meaningless, because the the attribute value "footnote()" does not contain an expression. The situation is different for the attribute values which may be used by table cell styles. They are "cell-content() op value", "cell-content-is between(value1, value2)", "cell-content-is-not-between(value, value)" and "is-true-formula(expression)" And later it is defined, that "value", "value1" and "value2" can be an /expression/. The namespace determined by the prefix or the default namespace is only applied to the /expression/. The same construct is used in 19.600 table:condition. There too, the namespace is only applied to /expression/. 19.639 table:expression is different. It has "The XML namespace name bound to the namespace prefix specifies the syntax and semantics of the formulas and values occurring within the condition." Because the structure only requires an '=' equal sign in case of a prefix and not other keywords occur, I would say, that the entire part after the '=' equal sign has to follow the syntax and semantics given by the namespace. 19.646 table:formula is similar to table:expression, only that is has not the special rule for a '=' equal sign. It has "The namespace bound to the prefix determines the syntax and semantics of the formula." 19.811 text:formula has "The text:formula attribute specifies the formula or expression used to compute the value of a field." and "The namespace bound to the prefix determines the syntax and semantics of the formula." Since the individual attribute specifications use the terms "formula" and "expression", I tried to include both. I have used the first paragraph in my proposal to indicate, that "formula" and "expression" are terms uses in the specification of the individual attributes. I thought that would be clearer than the current term "attribute value portions that are expressions determined by a prefix". And none of the other conditions are so defined. ?? ***** Not to mention that doesn't address our changing from "shall" support Part 4 (which was an error for style:condition) to some namespace with a default. ?? Thinking perhaps, not committed to this, that we should: 1) To Andreas' point, keep shall either use our namespace or default to it, but 2) May support other namespaces but that's not required for conformance, good for interoperability but allows conformance to remain as it is now. In my understanding the current conformance clause 2.2.1 D.3) does not say, that the namespace shall be "urn:oasis:names:tc:opendocument:xmlns:of:1.2". But it says, _if_ the used namespace is "urn:oasis:names:tc:opendocument:xmlns:of:1.2", then syntax and semantic shall conform to Part 4. For the table:formula attribute in Spreadsheet documents the namespace "urn:oasis:names:tc:opendocument:xmlns:of:1.2" is mandatory. That is in sections 2.2.4 D) and E). We should consider to make the namespace "urn:oasis:names:tc:opendocument:xmlns:of:1.2" mandatory for Spreadsheet documents not only for table:formula attribute but for table:condition, table:expression and style:condition attributes as well, since evaluators need to know syntax and semantic to produce correct cell values. (C) Add in each of the five attribute descriptions: Producer should only use the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace to ensure interoperability. Producers .... yes? Yes. Kind regards Regina