Subject: ODF Issues applied since last report
Greetings! I have attached a short form summary of the issues applied to ODF drafts starting 3 May and ending today. Hope everyone is having a great week! Patrick -- Patrick Durusau email@example.com 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: patrickDurusauTitle: OASIS Technical Committees Issue Tracker
|OASIS Technical Committees Issue Tracker|
|Displaying 18 issues at 09/May/18 9:11 PM.|
Allow <office:binary-data> in <draw:fill-image>
|ODF 1.2|| Change the description in section 16.40.6 <draw:fill-image> to this:
The <draw:fill-image> element specifies either a link to a bitmap resource or contains an image in the <office:binary-data> child element. Producers shall not write the <office:binary-data> child element in case the document is represented as a package.
Fill image are not available as automatic styles.
Change the schema this way:
--- OpenDocument-v1.2-os-schema.rng 2017-08-23 01:39:12.187248700 +0200
+++ OpenDocument-v1.2-os-schema_drawFillImage.rng 2017-08-28 22:38:25.626770100 +0200
@@ -14021,27 +14021,17 @@
- <attribute name="xlink:type">
- <attribute name="xlink:href">
- <ref name="anyIRI"/>
- <attribute name="xlink:show">
- <attribute name="xlink:actuate">
+ <ref name="common-draw-data-attlist"/>
+ <ref name="office-binary-data"/>
Problems in 20.226 presentation:display-date-time
|ODF 1.2|| 20.226 presentation:display-date-time
The presentation:display-date-time attribute specifies the visibility of a drawing shape from a <style:master-page> element, where the shape has the presentation class date-time.
The defined values for the presentation:display-date-time attribute are:
* false: drawing shape from a <style:master-page> element with the presentation class date-time should not be visible.
* true: drawing shape from a <style:master-page> element with the presentation class date-time should be visible.
The presentation:display-page-number attribute specifies the visibility of a drawing shape from a <style:master-page> element, where the shape has the presentation class page-number.
The defined values for the presentation:display-page-number attribute are:
* false: drawing shape from a <style:master-page> element with the presentation class page-number should not be visible.
* true: drawing shape from a <style:master-page> element with the presentation class page-number should be visible.
description<>schema for text:display in <text:_expression_> (19.796.3)
|ODF 1.2|| Remove the item
none: hides the content of a field.
from the description
fo:background-color (20.175) editorial errors
|ODF 1.2 Errata 01, ODF 1.3|| (1)
..., footers, tables, table rows and tables.
..., footers, table cells, table rows and tables.
Write "transparent" in in the correct template style.
wrong typographic for literal value "table" of style family in table:background
|ODF 1.2|| The table:style-name attribute specifies a <style:style> element of type table.
Herein in monospace font:
Section 20.194 fo:keep-with-next has wrong XSL reference
|ODF 1.2||Correct the reference in ODF 1.3 and in ODF 1.2 errata (in case there will be one).|
draw:image incorrectly allows text:list, text:p child elements
|ODF 1.2 Errata 01, ODF 1.3||insert after list- new para - Like most other drawing shapes, image drawing shapes may have text content. It is displayed in addition to the image data.|
ODFF: CRITBINOM constraints on Alpha
| "0 <= Alpha <= 1"
ODFF: RECEIVED function should have constraint settlement ≥ maturity
| 6.12.43 RECEIVED
should have the constraint Settlement < Maturity added.
Excel, Gnumeric and now LibreOffice implement it that way, else return
Function CELL Info_Type ADDRESS comment needs an amendment
| For spreadsheet function CELL Info_Type ADDRESS it currently reads
The sheet name is included if given in the reference.
This needs to be amended, e.g.
The sheet name is included if given in the reference and does not
reference the same sheet as the sheet the _expression_ is evaluated on.
DAYS360 third parameter should be Logical
| Syntax: DAYS360( DateParam StartDate ; DateParam EndDate [ ; Logical Method = FALSE() ] )
Semantics: If method is FALSE(), it uses the National Association of
Securities Dealers (NASD) method, also known as the U.S.
method. If the method is TRUE(), the European method is used.
and the constraints be removed.
DCOUNT and DCOUNTA Field argument can be omitted
|ODF 1.3||Accepted for ODF 1.3 as per 6 June 2016|
New Feature: reference Khronos standards for 3D model file formats like COLLADA and/or glTF
typo in ODF 1.2 part 3, 3.4.1 General missing word "size"
|ODF 1.2||insert "size" -> "may be of greater size"|
Public Comment: OpenDocument-v1.2-os-dsig-schema.rng Reference to ODF 1.3 Part 3
|ODF 1.2|| in OpenDocument-v1.2-os-dsig-schema.rng line 66 replace
"<!-- See OpenDocument v1.2 part 3, section 4.3. -->"
"<!-- See OpenDocument v1.2 part 3, section 5.3. -->"
PAS Comment JP2: Semantics of the interactions of the change-tracking elements are unclear
PAS Comment GB1: Request retention of ODF 1.1 as published standard
|ODF 1.2|| The UK recommends the retention/stabilisation of a consolidated text of ISO/IEC 26300: 2008 and its associated Corrigenda and Amendment.
PAS Comment JP5: Clarify relationship between digital signature and encryption
|ODF 1.2|| proposal for our response to this ODF 1.2 PAS Submission comment:
We agree that the current wording might cause an uncertainty regarding the relationship between encryption and digital signatures.
We suggest to replace the last two paragraphs of section 5.2 in Part 3 by:
"If a digital signature file is not encrypted, each encrypted file referenced by <ds:Reference> elements shall be signed in its encrypted form."
"If a digital signature file is encrypted, then the files referenced by <ds:Reference> elements shall be signed in their decrypted forms."
We also suggest to introduce a new section 3.9 "Interactions Between Encryption and Digital Signatures" with the following content:
"An OpenDocument Package Producer that both encrypts files in the package and applies digital signatures to files in the package should either first encrypt (per section 3.4) and then apply the digital signatures (per section 5) or first apply the digital signatures and then encrypt.
If the encryption of the files is done first, the digital signatures files shall not be encrypted.
If the files in the package are encrypted after applying the digital signatures, the digital signature files shall be encrypted.
See also section 5.2.
Note: It is current practice to first encrypt and then apply the digital signatures."
|Generated at Thu May 10 01:11:37 UTC 2018 by Patrick Durusau using JIRA 7.7.2#77003-sha1:2241faf4520a2d3eba4691b355732c8fd7579144.|
Description: OpenPGP digital signature