OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  JIRA issues for 21 December 2015

    Posted 12-07-2015 15:50
    -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! I have revised the spreadsheet to remove issues we processed this AM and have attached that revision for our meeting on 2015-21-12. Hope everyone is at the start of a great week! Patrick - -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWZarAAAoJEFPGsgi3Mgycz+IQAKY+qTSHGaD/xl4FCcIzrvk/ BirFtdqT6ZEe8y7cqFtV02EsOPZcNrEQPlI4NGI5gds0o/mxbmlYnlFcZmhp1v3r PCPopeqOd2Frs9NELTCASmStx8UbgK9E3wSgZGhupSjCF2hKxITRd0N6uctm3kzt B1ad+N4CiLvW5s0Ul+hCIBw/UmKF/eWdEzQnRobt3V2ZYWEecWkR1wKL6UIxSww0 XqKws1nl6muaNIfkOfvad+U5BKDC1PzjUHG4Ak8wVcq9tmWzF/0jvChoN86VuX/c dliEVjbVSAFVZuuv+QW0v4El+Zs90+xH03tJ8mJy61cl6te+mJIvpdwrerpXMqns tITgGrN6t1XbNLy2e3feQZAdUaajVw3bxjCCfZuYqyKup4dCKlQEL7HXoFBHOMpp dZpk7wDUe81B9xF9WOo80ZAhqK64yU3FXB8xpKxRvMbTnn8OFkOh/f+qMUf4V2GY WTeAJPaN5knF8hDGT6DanP8tLJSc4HU7yTiwTTU0wC9Z9CnLShrYv0Db7LAGcx6j eRIOryqTVKYEn1zTLfn/rdscHY5dxgxgdnLIxqOeDR43uI+nE27nQiOyK2AcXZms dZCxsWXTwIVPSUzpgoi3B0vHb5q6d928j+g1K6haakcuLrLHOr9a2HxW9yXUYxxa CAgXIjuR2C7W1ib5Tcjy =J4wP -----END PGP SIGNATURE----- Attachment: JIRA-Issues-ODF-TC-21December2015.ods Description: application/vnd.oasis.opendocument.spreadsheet


  • 2.  Re: [office] JIRA issues for 21 December 2015

    Posted 12-14-2015 00:56
    Hi all, Patrick Durusau schrieb: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! I have revised the spreadsheet to remove issues we processed this AM and have attached that revision for our meeting on 2015-21-12. Hope everyone is at the start of a great week! some comments: https://issues.oasis-open.org/browse/OFFICE-1253 The reporter does not request the page or line break itself, but he wants to get a page or line number that is stable, so that it can be used in citations. An additional attribute "value" for the number in the last rendering might help, or a readonly "archive" format for the whole file. But feature request should go to implementers first, so I agree with closing. ================================================= https://issues.oasis-open.org/browse/OFFICE-1263 We have seen exact the same problem, when we decide to use svn for the specification documents. If Jos is willing to take it, he might identify possible changes/additions to the standard, that would be helpful for common Content Managemant Systems. Or Svante might take it and handle it together with change tracking. The issue https://issues.oasis-open.org/browse/OFFICE-3788 “Make xml:ids stable over the lifetime of a document” might be related. That issue has Patrick as assignee. I think it is worth to consider, but it needs an assignee then. Only target ODF 1.3 is optimistic. ================================================= https://issues.oasis-open.org/browse/OFFICE-1276 This issue is strong related to issue https://issues.oasis-open.org/browse/OFFICE-3886 “Extend Open Document Specification to improve support for bibliographies.” which has as assignee Thomas O'Reilly. Therefore I suggest to close it as duplicate of OFFICE-3886 or the other way round. In addition we should ask Thomas, if he actually wants to work on issue OFFICE-3886, otherwise we need a new assignee, if it is intended to solve it for ODF1.3 ================================================= https://issues.oasis-open.org/browse/OFFICE-1277 There is a long discussion (19 mails!) in the thread https://lists.oasis-open.org/archives/office-comment/200903/threads.html#00001 It needs a volunteer to sort this out. Office-1306 is duplicate to this. OFFICE-2409 and OFFICE-2599 are related. There is no need for a common scripting language. LibreOffice and Apache OpenOffice have the ability to use several languages. The real problem is, that the scripting language works on the model, that the implementation uses. So LO/AOO have an own API, which not only addresses the document itself but the UI and information about the user too. Those parts cannot work for other implementations with their own models. The document parts can be specified. ODF needs a common DOM, similar as it is defined for HTML. That it not depending on any implementation. Implementers, especially LO/AOO would need to map it to their API. Because a lot of macros exist, dropping the API of LO/AOO is no option. Specifying a DOM would be a task for the TC, not for implementers. For to get more interoperability in macros, I think it need to be done. But it is a large task and do we have volunteers to bring it forward? It is too large to be done in spare time. ================================================= https://issues.oasis-open.org/browse/OFFICE-1283 LibreOffice and Apache OpenOffice have this file type implemented. Therefore it should not be dropped, but specified. It belongs into 2.2.3 OpenDocument Text Document ================================================= https://issues.oasis-open.org/browse/OFFICE-1286 The issue is not about XForms but about an attribute of the <form:form> or <form:textarea> element or any of the other controls. LibreOffice and Apache OpenOffice use this attribute. There is even an issue, that LO and AOO depend on it, although the attribute is optional. The issue OFFICE-1286 seems to belong to http://tools.oasis-open.org/version-control/browse/wsvn/oic/Advisories/00003-form_control_fallback/trunk/description.html . The recommendation there has been implemented in ODF 1.2. The specification in '19.258 form:control-implementation' has the text "If the consumer supports the form element this attribute is used with, but does not support the specific concrete rendition or implementation, the consumer shall ignore the form:control-implementation attribute and use its own rendition of the form element." I see no need to remove the attribute and suggest to close the issue. ================================================= Kind regards Regina


  • 3.  Re: [office] JIRA issues for 21 December 2015

    Posted 12-15-2015 02:19
    Concerning issue https :// issues.oasis- open.org /browse/OFFICE-1276  - dealing with bibliography modelling: I think should OFFICE-1276 should be combined with the issue I submitted https :// issues.oasis- open.org /browse/OFFICE-3886 . I am currently working on OFFICE-3886. I don't know if I will be finished by ODF 1.3; I don't do anything fast. I am currently surveying other bibliography systems. My (rough) work in progress is hosted at http://www.odf-bibliography.com. Sent from Outlook Mobile On Sun, Dec 13, 2015 at 4:55 PM -0800, "Regina Henschel" < regina.henschel@libreoffice.org > wrote: Hi all, Patrick Durusau schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greetings! > > I have revised the spreadsheet to remove issues we processed this AM > and have attached that revision for our meeting on 2015-21-12. > > Hope everyone is at the start of a great week! > some comments: https://issues.oasis-open.org/browse/OFFICE-1253 The reporter does not request the page or line break itself, but he wants to get a page or line number that is stable, so that it can be used in citations. An additional attribute "value" for the number in the last rendering might help, or a readonly "archive" format for the whole file. But feature request should go to implementers first, so I agree with closing. ================================================= https://issues.oasis-open.org/browse/OFFICE-1263 We have seen exact the same problem, when we decide to use svn for the specification documents. If Jos is willing to take it, he might identify possible changes/additions to the standard, that would be helpful for common Content Managemant Systems. Or Svante might take it and handle it together with change tracking. The issue https://issues.oasis-open.org/browse/OFFICE-3788 “Make xml:ids stable over the lifetime of a document” might be related. That issue has Patrick as assignee. I think it is worth to consider, but it needs an assignee then. Only target ODF 1.3 is optimistic. ================================================= https://issues.oasis-open.org/browse/OFFICE-1276 This issue is strong related to issue https://issues.oasis-open.org/browse/OFFICE-3886 “Extend Open Document Specification to improve support for bibliographies.” which has as assignee Thomas O'Reilly. Therefore I suggest to close it as duplicate of OFFICE-3886 or the other way round. In addition we should ask Thomas, if he actually wants to work on issue OFFICE-3886, otherwise we need a new assignee, if it is intended to solve it for ODF1.3 ================================================= https://issues.oasis-open.org/browse/OFFICE-1277 There is a long discussion (19 mails!) in the thread https://lists.oasis-open.org/archives/office-comment/200903/threads.html#00001 It needs a volunteer to sort this out. Office-1306 is duplicate to this. OFFICE-2409 and OFFICE-2599 are related. There is no need for a common scripting language. LibreOffice and Apache OpenOffice have the ability to use several languages. The real problem is, that the scripting language works on the model, that the implementation uses. So LO/AOO have an own API, which not only addresses the document itself but the UI and information about the user too. Those parts cannot work for other implementations with their own models. The document parts can be specified. ODF needs a common DOM, similar as it is defined for HTML. That it not depending on any implementation. Implementers, especially LO/AOO would need to map it to their API. Because a lot of macros exist, dropping the API of LO/AOO is no option. Specifying a DOM would be a task for the TC, not for implementers. For to get more interoperability in macros, I think it need to be done. But it is a large task and do we have volunteers to bring it forward? It is too large to be done in spare time. ================================================= https://issues.oasis-open.org/browse/OFFICE-1283 LibreOffice and Apache OpenOffice have this file type implemented. Therefore it should not be dropped, but specified. It belongs into 2.2.3 OpenDocument Text Document ================================================= https://issues.oasis-open.org/browse/OFFICE-1286 The issue is not about XForms but about an attribute of the <form:form> or <form:textarea> element or any of the other controls. LibreOffice and Apache OpenOffice use this attribute. There is even an issue, that LO and AOO depend on it, although the attribute is optional. The issue OFFICE-1286 seems to belong to http://tools.oasis-open.org/version-control/browse/wsvn/oic/Advisories/00003-form_control_fallback/trunk/description.html . The recommendation there has been implemented in ODF 1.2. The specification in '19.258 form:control-implementation' has the text "If the consumer supports the form element this attribute is used with, but does not support the specific concrete rendition or implementation, the consumer shall ignore the form:control-implementation attribute and use its own rendition of the form element." I see no need to remove the attribute and suggest to close the issue. ================================================= Kind regards Regina --------------------------------------------------------------------- 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


  • 4.  Re: [office] JIRA issues for 21 December 2015

    Posted 12-15-2015 20:46
    Hi, Regina Henschel schrieb: https://issues.oasis-open.org/browse/OFFICE-1286 The issue is not about XForms but about an attribute of the <form:form> or <form:textarea> element or any of the other controls. LibreOffice and Apache OpenOffice use this attribute. There is even an issue, that LO and AOO depend on it, although the attribute is optional. Just tested again: LibreOffice has no problem when the attribute is missing, only Apache OpenOffice fails to show the control, when this attribute is missing. Kind regards