Update on applied issues for 30 May 2018

[Patrick Durusau <patrick@durusau.net>]

Greetings!

I made some progress on applying resolved issues as you can see from the
current drafts and/or the attached JIRA report.

There are a myriad of things left to do but most important are your
PROPOSALS for next Monday!

I'll post a skeleton agenda with the issues I know about tomorrow but
please send email if you have issues with proposals ready for acceptance
by the TC.

Hope everyone is having a great week!

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 

OASIS Technical Committees Issue Tracker
OASIS Technical Committees Issue Tracker

Displaying *43* issues at *30/May/18 10:26 PM*. Key Summary Affects Version/s Proposal Issue Type OFFICE-3905 LINEST and LOGEST should have ForceArray parameter types ODF 1.3 see description. Bug OFFICE-3902 Missing ForceArray parameter types ODF 1.2, ODF 1.3 Agreed at ODF TC meeting to this issue and to set for ODF 1.3. Bug OFFICE-3848 Error in matrix description in 19.107 dr3d:transform ODF 1.2 Change it to 3x4 in ODF1.2 Errata. There has already been issue OFFICE-2400 about the same topic. Apparently such descriptions are confusing. Therefore I suggest to write the full transformation matrix in ODF1.3. The spec is in .odt format and we have a nice formula editor, so there is no problem in writing a nice matrix. Proposal: "matrix( ): specifies a transformation in the form of a homogeneous transformation matrix a d g j b e h k c f i l 0 0 0 1 where the values (, , ) in the right column describe the translation. " Bug OFFICE-3823 trigonometric functions in attribute draw:formula (19.171, part1 ODF1.2) specify angle in degree but widely implemented as radian ODF 1.2 Change the text "degree" to "radian". Current text: sin(n) returns the trigonometric sine of n, where n is an angle specified in degrees cos(n) returns the trigonometric cosine of n, where n is an angle specified in degrees tan(n) returns the trigonometric tangent of n, where n is an angle specified in degrees atan(n) returns the arc tangent of n in degrees atan2(x,y) returns the angle in degrees of the <..> with the x-axis Proposed text: sin(n) returns the trigonometric sine of n, where n is an angle specified in radians cos(n) returns the trigonometric cosine of n, where n is an angle specified in radians tan(n) returns the trigonometric tangent of n, where n is an angle specified in radians atan(n) returns the arc tangent of n in radians atan2<..> returns the angle in radians of the vector (x,y) with the x-axis I have skipped "(x,y)" here, because that is in issue OFFICE-3822. Bug OFFICE-3822 atan2 in attribute draw:formula (19.171, part 1 ODF1.2) has wrong order of arguments ODF 1.2 Current text: atan2(x,y) returns the angle <...> of the vector (x,y) with the x-axis Proposed text: atan2(y,x) returns the angle <..> of the vector (x,y) with the x-axis I have skipped the part "in degrees" here, because that is an additional problem, for which I will write another issue. Bug OFFICE-3789 [text] Proposal: special header/footer style on first page 1. RATIONALE 1.1 Use cases: Sometimes users want different header/footer not only on left/right pages, but also on the first page. If style:header-first/style:footer-first elements are present, then the fist page with which the master-page is rendered get the header/footer defined by style:header-first resp. style:footer-first. 1.2 Alternatives considered: Right now a possible workaround is to use one page style on the first page, and an other on the left/right pages, but that is clumsy. 2. REQUESTED CHANGES TO THE ODF STANDARD 2.1 Text changes/additions: In section 5.1.3 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 5.3.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 5.4.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 5.5.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 5.5.7.2 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 5.5.7.3 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 5.5.7.4 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 7.4.2 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 7.4.7 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 7.4.11 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.2.3 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.3.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.4.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.5.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.6.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.7.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.8.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.8.3 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 8.9.1 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 9.1.2 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 14.6.2 append to the end of "usable within the following elements": style:header-first, style:footer-first In section 16.9 append to the end of child elements: style:header-first, style:footer-first 16.x: style:header-first (new section) The element represents the content for a header for a first page, if different from the left/right page in a element. The element represents the content for a header for a first page. Hereby the term "first page" means the first page to which the page style is applied, regardless of any numbering. If a different page style is applied in between two applications of the page style, that has the element, each of the applications of the page style has its own first page. The element is usable within the following element: 16.9. The element has the following attribute: style:display 19.471. The element has the following child elements: 16.15, 16.14, 16.16, 9.1.2, 8.8, 8.8.3, 8.9, 5.5.7.4, 5.5.7.3, 5.5.7.2, 14.6.2, 5.1.2, 8.4, 8.2.3, 5.3.1, 8.6, 5.1.3, 5.4, 7.4.11, 8.5, 8.3, 5.5.1, 7.4.7, 8.7 and 7.4.2. 16.x: style:footer-first (new section) The element represents the content for a footer for a first page, if different from the left/right page in a element. The element represents the content for a footer for a first page. Hereby the term "first page" means the first page to which the page style is applied, regardless of any numbering. If a different page style is applied in between two applications of the page style, that has the element, each of the applications of the page style has its own first page. The element is usable within the following element: 16.9. The element has the following attribute: style:display 19.471. The element has the following child elements: 16.15, 16.14, 16.16, 9.1.2, 8.8, 8.8.3, 8.9, 5.5.7.4, 5.5.7.3, 5.5.7.2, 14.6.2, 5.1.2, 8.4, 8.2.3, 5.3.1, 8.6, 5.1.3, 5.4, 7.4.11, 8.5, 8.3, 5.5.1, 7.4.7, 8.7 and 7.4.2. 2.2 Schema changes/additions: See patch at https://www.oasis-open.org/apps/org/workgroup/office/download.php/47159/12-10-11-proposal00093 3. IMPACTS 3.1 Conformance: This proposal will not add any mandatory features or behaviors. 3.2 Backwards compatibility: This element was not used in previous versions and is optional. Existing ODF processors may ignore it, still displaying the left (if present) or right header/footer, as before. 3.3 Accessibility impact: None. Improvement OFFICE-3776 [text] Proposal: initials of annotation authors 1. RATIONALE 1.1 Use cases: Users sometimes want to track the initials of annotation authors. 1.2 Alternatives considered: None. 2. REQUESTED CHANGES TO THE ODF STANDARD 2.1 Text changes/additions: Add item 14.4 The element represents the initials of the author of the annotation. In section 14.1 append to the end of child elements: meta:creator-initials 2.2 Schema changes/additions: {noformat} --- Downloads/OpenDocument-v1.2-os-schema.rng 2018-04-06 13:21:47.000000000 +0200 +++ OFFICE-3776.rng 2018-05-07 11:50:01.838420540 +0200 @@ -11160,30 +11160,35 @@ + + + + + {noformat} 3. IMPACTS 3.1 Conformance: This proposal will not add any mandatory features or behaviors. 3.2 Backwards compatibility: This element was not used in this context in previous versions and is optional. Existing ODF processors may ignore it. 3.3 Accessibility impact: None. Improvement OFFICE-3765 [spreadsheet] Proposal: element for data styles Updated 30 April 2018 to reflect proposal up for TC approval: Regina Henschel's proposal for the text (changed does not to shall not in the second sentence) In section 16.27 Data Styles [http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part1.html#__RefHeading__1416346_253892949] add: New element: The content of this element specifies a Unicode character that is displayed repeatedly at the position where the element occurs. The character specified is repeated as many times as possible, but the total resulting string shall not exceed the given cell content area. Fill characters may not fill all the available space in a cell. The distribution of the remaining space is implementation dependent. To chapter "16.27.1 General" add the sentence: Data styles shall specify at most one element. Michael Stahl's schema prooposal: {noformat} --- Downloads/OpenDocument-v1.2-os-schema.rng 2018-04-06 13:21:47.000000000 +0200 +++ OFFICE-3765.rng-v2 2018-04-26 16:29:04.895877657 +0200 @@ -12608,20 +12608,20 @@ - + - + @@ -12712,15 +12712,15 @@ - + @@ -12738,21 +12738,21 @@ - + - + @@ -12782,15 +12782,15 @@ - + @@ -12801,20 +12801,20 @@ - + - + @@ -12958,20 +12958,20 @@ - + - + @@ -13078,27 +13078,43 @@ - + - + + + + + + + + + + + + + + + + + {noformat} Improvement OFFICE-3757 Public Comment: COVAR formular is missing factor 1/N ODF 1.2 Semantics: returns 1/N\times (existing formula) where \bar{n1} is the result of calling AVERAGE(n1), bar{n1} is the result of calling AVERAGE(n2), and N is the number of terms in the sum. Bug OFFICE-3742 Public Comment: ODF1.2 draw:style rect/round vs svg:stroke-linecap ODF 1.2 (1) Add following sentences to section 20.164 svg:stroke-linecap: For a dashed line, caps are applied to each dash. The values of the draw:dots1-length, draw:dots2-length and draw:distance attributes of the referenced element refer to the dashes without cap. If the referenced element has an attribute draw:style, the attribute draw:style is ignored. (2) In section 19.218.5 add: This attribute is evaluated for a shape if its style does not contain an svg:stroke-linecap attribute. Bug OFFICE-3684 Public Comment: CS01 "ODF Consumer" -> "OpenDocument Consumer" Bug OFFICE-3671 Public Comment: 19.147: draw:escape-direction, unable to arbitrarily combine directions ODF 1.2 CD 07 Bug OFFICE-3508 Public Comment: ODF-Next: Group element - was: Proposal for Preferred Selection inText Documents ODF 1.2 CD 05 Bug OFFICE-3507 Public Comment: ODF-Next: Proposal for Preferred Selection in Text Documents ODF 1.2 CD 05 New Feature OFFICE-3475 not place to put RDF in flat ODF document ODF 1.2 CD 05 Store the RDF parts in special child element of called wchi will contain elements that correspond to the rdf files. So ... ... Bug OFFICE-3449 ODF 1.2 CD05 Part 1 5.5.3 Text Insertion Interoperable Definition Required ODF 1.2 CD 05 [Dennis' proposal:] Again ,the stakeholders of this provision must assist in arriving at an interoperably-implementable description of what current implementations manage for ODF 1.0/1.1. 1. Define what constitutes a legitimate single insertion selection and how it relates to other occurrences of insertion selections. Must they be non-overlapping? May they be nested? We want a case for allowed insertion selections that are implemented and that shall be supported by a conforming implementation that supports tracked changes shall be able to present the insertion (if that is a consumer capability) and to reject the insertion (if rejection is a consumer capability). [Note: there is no concern, here, for what a producer might turn into multiple insertions to accomodate an operation provided for processing of a document, only what one must be prepared to recognize as a single selection in the document. 2. How much of healing across a tracked deletion is involved when healing across the deletion that rejection of an insertion is? 3-4 omitted because they seem to be irrelevant in this case. 5. Edge cases: Whether deletions can occur that remove part of an insertion selection, and if so, what is done about the curing the broken connection between and its matching ? I have the same sense of what works as implementation-defined and implementation-dependent requiring that there be some useful remainder that can be interoperably implemented and that a consumer can detect whether it can deal with whatever else shows up in regard to tracked insertions. [Note: I have stayed away from use cases, although there is obviously an interest among implementers in seeing how what is provided works with interesting cases, such as a cut and paste operation that leaves deletions and results in insertions. Also pasting over a selection leads to deletions and insertions at the destination. I don't think we can speak to that, although there is some concern that what is well-defined in the format can be usable in such manipulations. Undo, which does not leave residue in conforming markup of the produced document, is also a consideration for implementers nonetheless.] This is simpler than tracked deletion alt [Oliver's proposal:] Use the information given at Dennis' proposal for an improved or new ODF change tracking for the next version of ODF. Bug OFFICE-3448 ODF 1.2 CD05 Part 1 - 5.5.4 Text Deletion Interoperable Definition Required ODF 1.2 CD 05 [Dennis' proposal:] The stakeholders in this provision need to offer what works here from their knowledge of existing implementations of ODF 1.0/1.1. 1. Define what constitutes a single selection that shall be supported by a confirming implementation of tracked-change deletions and that a consumer that supports the feature shall be able to present (if that is a consumer capability) and to reject the change (if that is a claimed consumer capability). [Note, this is not what makes a single selection at the UI, but what is turned into a single-deletion selection and may well be part of a larger selection that a producer allows to be made as part of processing a document.] 2. The question is basically, what is the original case of a span of markup that can be replaced by a single element: 2.1 If it is admissable to cut off start tags before the deletion selection from their end tags within the selection, and start tags within the selection from their end tags that are beyond the end of the selection, what are the conditions that must be satisfied between those respective elements that will be torn at the front of the selection and those torn at the rear of the selection? 2.2 What is the rule for healing the scar left by the removal of the selected markup and replacement by the element. 3. The next question is how, for such a deletion, is the deleted markup repaired so that those end tags in the selection that have no longer have start tags are made well-formed elements. Likewise, how is the deleted markup repairs so that those start tags in the selection that have no longer have end tags are made well-formed elements, such that the entire deletion material in the is well-formed. 4. Finally, what additional must be done to the material, no matter what adjustments were made, to ensure that it is unambiguously restorable in the event that the deletion is rejected. [This should also be sufficient that a consumer that is implemented to show tracked deletions can do so reliably.] 5. Edge cases: Describe whether deletions selections can occur in deleted material that is being shown as tracked but not rejected. Can the selection cross out of the deletion material or must it be entirely within or entirely without? If some of these cases or extending beyond them is implementation-defined or implementation-dependent, that strikes me as eminently reasonable. However, I believe a well-defined interoperably-implementable case must remain, such that a consumer can also determine whether it can handle whatever else shows up in a tracked deletion. [Oliver's proposal:] Use the information given at Dennis' proposal for an improved or new ODF change tracking for the next version of ODF Bug OFFICE-3436 ODF 1.2 CD05 Part 2 6.13.3 CELL Assumptions Too Host-Dependent ODF 1.2 CD 05 1. Determine what the overall policy is for the way host-dependent provisions are to be handled interoperably for this function (and perhaps for this section). 2. Break this issue into subtasks for resolving the individual cases that arise for this particular composite function. Bug OFFICE-3429 Unicode Normalization needed for OpenFormula ODF 1.2 CD 05 New Feature OFFICE-3420 Public Comment: Request for fixing problems in handling Kihon-hanmen in ODF 1.2 ODF 1.2 CD 05 Bug OFFICE-3417 Public Comment: Comment on ODF v1.2 CD 05 - Document Signatures ODF 1.2 CD 05 Bug OFFICE-3415 Public Comment: Yomi (xml:lang missing for dc:title, dc:subject, dc:creator, etc.) ODF 1.2 CD 05 Bug OFFICE-3404 9.1.13 - confusing naming of table:title element ODF 1.2 CD 05 Bug OFFICE-3383 ODF 1.2-1 5.5.6 content overkill ODF 1.2 CD 05 Dennis' proposal: 1. Remove the provision for or, if there are actually implementations that exist for this, deprecate it. 2. Adopt as the optional companion to the and elements that are already employed. This is all metadata. Oliver's proposal: Still allow elements as comments for tracked changes, but restrict the child elements of the element which occurs inside the . Bug OFFICE-3356 Public Comment: Please standardize "Line Start Prohibition Rule" ODF 1.2 CD 05 Bug OFFICE-3325 OpenFormula 3.4 HOST-REFERENCE-RESOLVER under-defined ODF 1.2 CD 05 Bug OFFICE-3323 OpenFormula 3.4 HOST-REFERENCE-RESOLVER should not be implementation defined ODF 1.2 CD 05 Remove the qualification "is implementation defined." (Note, other changes may impact how this is accomplished.) Bug OFFICE-3034 Public Comment: Requirement ODF 1.2 CD 05 Bug OFFICE-3031 Public Comment: Comment on bibliographic section of ODF ODF 1.2 CD 05 Bug OFFICE-3030 Public Comment: Comments on Digital Signatures in ODF 1.2 Part 3 ODF 1.2 CD 05 Bug OFFICE-3022 14.1 currently not usable with ODF 1.2 CD 05 add to the list of elements can is usable with Improvement OFFICE-2925 19.315 form:validation - scope of validation - see description ODF 1.2 CD 05 Bug OFFICE-2846 Public Comment: Requirement ODF 1.2 CD 05 Bug OFFICE-2707 ODF 1.2 Section 5.1 No Longer Differentiates In-Line Text ODF 1.2 CD 05 In Appendix G, in the list at the beginning of G.1, add the item "The concept of in-line text is removed (5.1). There is no longer any such differentiation among the ways and elements appear under different ancestor elements." Bug OFFICE-2702 Public Comment: ODF New Proposal: Generic Format-Handling Functions ODF 1.2 CD 05 Bug OFFICE-2688 Support Kihon-hanmen (Japanese grid-based page layout) ODF 1.2 CD 05 Bug OFFICE-2687 ODF 1.2 Part 3: Unspecified Signature-File Name Allocation ODF 1.2 CD 05 1. If META-INF/documentsignatures.xml is intended to always mean full-package signature, reserve it for that purpose in Part 3 and be specific about what it signs. ODF 1.2 Part 1 can then required this signature when there are any signatures in a package. 2. Define the name pattern 'META-INF/tld.host.s3. ... . sn/*' to identify an implementation-defined file for which the authoritative definition is associated with the namespace URI "http://host.tld/s3/.../sn". Such files are defined to be authorittaively-named and the authorittaive definitiion determines further provisions on name structure, file format, and limitations on use and conformance provisions where the files are usable. 3. An authoritatively-named digital signature file is any one where the name pattern '/META-INF/*signatures*' is also satisfied and the file conforms to those requirements along with those of the authoritative definition. 4. For Conforming OpenDocument Packages, all of the allowed signature files should be authoritatively-named, where /META-INF/document-signatures.xml is included. (It might be taken as having an implicit namespace URL that is under OASIS.) 5. For Conforming OpenDocument Extended Packages, I would require the use of authoritative names there as well, since it is difficult to allow some unknown style to be intermixed unless there is never any confusion with authoritative names. Bug OFFICE-2668 manifest:preferred-view-mode: add some options ODF 1.2 CD 05 New Feature OFFICE-2623 Public Comment: ODF 1.2 comment: support for font embedding ODF 1.2 CD 05 New Feature OFFICE-2248 Parameter definitions for financial functions are spread across those functions and are inconsistent ODF 1.2 CD 05 I propose to gather up all the parameters for definition under 15.12.1 so that: 1) we can have one consistent definition for any given parameter 2) we can note and mark/explain when the use of a term changes Advice from the formula group would be appreciated. I am going to leave this issue and return to creating anchors and correcting prose. I did want to make a note of it so others could start looking at it. I don't know if this sort of inconsistency extends to other sets of functions but it would be helpful if someone wants to check. Bug OFFICE-2226 OFFICE-916 ODDFYIELD: is yield irrespective? ODF 1.2 CD 05 To ODDFPRICE, add the formula given in http://lists.oasis-open.org/archives/office-formula/201005/msg00013.html TODO: In ODDFYIELD find some wording and possibly algorithm for "It is solved iteratively using ODDFPRICE". Sub-task OFFICE-2208 New Statistical functions to meet best practices included in Excel 2010 Improvement OFFICE-2122 Member Proposal: draw:z-index semantics 19.231 draw:z-index, add this: The draw:z-index values increase from back to front. For a shape on which the attribute *style:run-through* (20.343) with value *foreground* is in effect, producers should not generate a *draw:z-index* value that is smaller than the value of any *draw:z-index* on a shape on which the attribute *style:run-through* with value *background* is in effect. Producers SHALL NOT generate a *draw:z-index* for shapes that are children of a element (10.3.15) or a element (10.5.2). 20.343 style:run-through, add this: The default value for this attribute is *foreground*. New Feature Generated at Thu May 31 02:26:02 UTC 2018 by Patrick Durusau using JIRA 7.7.2#77003-sha1:2241faf4520a2d3eba4691b355732c8fd7579144.

Attachment: signature.asc
Description: OpenPGP digital signature