Notes 15 June 2020

[Patrick Durusau <patrick@durusau.net>]

Greetings,

Notes from today's meeting appear below.

Hope everyone is at the start of a great week!

Patrick

*******************************

Patrick: 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 8 June 2020 (below)

4. ODF Later issues (Preference to current TC members and cycling
through their issues so no one is on the spot for all of them in a
meeting), btw, limiting the search to open/deferred issues counts 134:
https://issues.oasis-open.org/issues/?jql=project%20%3D%20OFFICE%20AND%20status%20in%20(Open%2C%20Deferred)%20AND%20fixVersion%20in%20(%22ODF%201.4%22%2C%20ODF-Next)%20ORDER%20BY%20reporter%20ASC
)

5. Resolving the manifest schema issue without another public review.
Specify to the TC admin that the only change is reflected in
https://issues.oasis-open.org/browse/OFFICE-4046, which was not an ODF
TC decision but a clerical omission. Starts another electronic ballot on
approval as TC Specification.

6. Roadmap from either our current draft or csd03
(https://www.oasis-open.org/apps/org/workgroup/office/download.php/67286/odf1.3-csd03.zip)
to OASIS standard (Svante asked about this and there is no useful
graphic from OASIS that captures the process. The attached document is
itself a summary of the steps, with several unlisted paths.)

7. BTW, some questions have been asked about the completeness of minutes
of our meetings. At the start of every call I ask if there are changes
or additions. Even better would be to enter any corrections while the
meeting is ongoing. I'm not shy about sharing the chat room!

8. Other issues?

9. Adjournment

*****

Changes or additions welcome!

Hope everyone is at the start of a great week!

Patrick

*************************************************



Patrick: We have quorum.
Patrick: Agenda - approved by consent
Patrick: Minutes from 11 May 2020 - approved by consent -
Patrick: 5. Holidays for the rest of 2020 - 2021
Patrick: US Labor Day - 7 September 2020
Patrick: Columbus 12 Oct 2020
Michael Stahl: none in DE for rest of 2020
Patrick: 22 Nov. 2020 - for Thanksgiving
Patrick: 21st and 28th of December
Patrick: 7 Sept, 12 Oct, 22 Nov -
Patrick: Holidays thus far for 2020 7 Sept., 12 Oct., 23 Nov., 28th Dec. -
Patrick: Approved by consent
Patrick: 6. Github - odf -
Patrick: who to list maintainers?
Svante Schubert: Some from the TC, Michael and I might volunteer
Svante Schubert: Because we are using GitHub for ODF toolkit
Svante Schubert: And I would suggest to name the reprository odf-tc or
odftc. As it is related to ODF and TC the TC makes sense in the default
name.
Svante Schubert: I stumbled over another example:
https://github.com/tc39/ecma262/releases/tag/es2020
The repro name here is ecma262.
Patrick: Svante and Michael Stahl as maintainers - volunteers
Svante Schubert: "odf-tc"
Patrick: with no objection odf-tc
Patrick: Regina - wants something for tools - xslt - scripts -
Svante Schubert: Regina: We want something for tools.
Patrick: under the top level repository - tools
Svante Schubert: Michael and me come up with a directory structure
suggestion for GitHub
Patrick: To post to mailing list for discussion
Patrick: https://issues.oasis-open.org/browse/OFFICE-4073
Patrick: (there is a typo in the agenda, 4047 should read: office-4074)
Patrick: Sorry, not an error at all!
https://issues.oasis-open.org/browse/OFFICE-4047
Regina Henschel: page-content-bottom determines a base for the value
given by "from-top" of 20.397
Patrick: office-4073 for - ODF 1.4 accepted
Michael Stahl: loext:vertical-rel in schema proposal has wrong namespace
Patrick: opened in JIRA, awaiting draft from Regina
Patrick: Accepted and awaiting final proposal
Patrick: https://issues.oasis-open.org/browse/OFFICE-4047
Patrick: default should be set to true
Svante Schubert: The default value true should be added.
Patrick: Svante - need to define what overlapping means?
Svante Schubert: The semantic of 'overlapping' might be a good to define
more precisly (with examples)
Regina Henschel: 20.181
Patrick: in ODF 1.3
Svante Schubert:
https://docs.oasis-open.org/office/OpenDocument/v1.3/cs01/part3-schema/OpenDocument-v1.3-cs01-part3-schema.html#__RefHeading__1419776_253892949
Patrick: Office-4047 for ODF 1.4 - accepted - specific proposal to
follow on mailing list
Patrick: Empty cell discussion - deferred because Andreas is absent -
note for tracking.
Patrick: Status update regarding ODF 1.3 manifest schema issue
Regina Henschel: https://issues.oasis-open.org/browse/OFFICE-4046
Michael Stahl: i don't think it's required for us to fix this in ODF 1.3
because this pattern is only used by one attribute and i'm not aware of
an application that uses a value corresponding to this QName pattern
Michael Stahl: the attribute is manifestreferred-view-mode
Patrick: Ascertain status on adoption of ODF 1.3 for next week -
Michael Stahl: PowerPoint supports the value "presentation-slide-show"
which is separate from QName pattern
Regina Henschel: To add to the
agenda:https://issues.oasis-open.org/browse/OFFICE-3768 ,
https://issues.oasis-open.org/browse/OFFICE-4073
Patrick: We have quorum
Svante Schubert: No objections to add aboves two issues to the agenda!
Patrick: Add Office-3768 and Office-4073 - by consent
Patrick: Agenda approved by consent -
Patrick: Minutes from June 8, 2020 - approved by consent -
Patrick: Svante suggests that we post a link to the email archive for
the minutes instead of reposting
Patrick: Alfred talk about status? Yes, on the agenda
Patrick: https://issues.oasis-open.org/browse/OFFICE-3768
Patrick: 4.7 Empty Cell terminology
Regina Henschel: 13. May
Patrick: Regina's solution:
https://www.oasis-open.org/apps/org/workgroup/office/email/archives/202005/msg00020.html
Svante Schubert: The history to empty cell was when isBlank is true, it
should be as well an "empty Cell"
Svante Schubert: isBlank is true, if there is calcuable content, so we
have "only" define which content is calcuable and which not?
Patrick: From Regina's proposal:
The value type of each of these elements shall be specified. The default
value type is void.
If the value type is neither string nor void, the corresponding Value
Attribute(s) (Table 14 - Value attributes) shall contain the value(s) of
the element. If the attribute is used for a table cell and the visual
representation differs from the value of the element, the cell element
shall have one <textï> child element, which contains the visible
representation.
If the value type is string and the office:string-value attribute is not
present and the attribute is not used for a table cell, then the element
content defines the value.
If the value type is string and the attribute is used for a table cell
and the table cell has one <textï> child element, which character
content 6.1.1 is the value of the element, then the office:string-value
attribute may be omitted.
Svante Schubert: Could we take one step back, what is not calcuable
content: Like an attached chart within an XML is not caluable.
Svante Schubert: Regina: Office annotations and any kind of graphic objects
Patrick: Empty cell 4.7 as proposed by Regina:

he technical term empty cell is used in this part of the specification
in defining functions and expressions. The technical term empty cell
stands for a cell with attribute office:value-type="void" (19.389 in
part 3 of the specification).
Note: An empty cell can still have child elements, for example shapes or
annotations, but those are not considered for calculations.
Note: The section 9.1.4 table:table-cell in part 3 of the specification
specifies restrictions for cell content in tables in spreadsheets.
Svante Schubert: "Empty cells" should be shown without content!
Patrick: Andreas - if annotation added to cell in spreadsheet,
calculation should not change.
Patrick: Regina - want a distinction in spreadsheets of what you can
calculate on and what you cannot -
Patrick: Andreas - empty string looks very much like nothing
Patrick: Need to be clear if empty string or nothing
Andreas Guelzow: my headset just went out of juice, be back in a moment.
Svante Schubert: I do not like to have an office:value-type on all
content cells. This is boilerplate.
Patrick: Another item from Regina's proposal:
The office:value-type attribute specifies the value-type of a table
cell (<table:change-track-table-cell>, <table:covered-table-cell> and
<table:table-cell>), a text field (<text:expression>,
<text:user-field-decl>, <text:variable-decl>, <text:variable-input>and
<text:variable-set>), or a form property (<form:list-value> and
<formïroperty>).
It specifies a default value type of database columns and database
column definitions (<db:column>12.35 and <db:column-definition>12.40).
The value type of each of these elements shall be specified. The default
value type is void.
Patrick: Svante wants to define the conditions for void - Regina
responds we are doing writer tables and spreadsheets
Patrick: The shall applies to all object elements - not writing it is
simply void.
Svante Schubert: I want to omit as much the office:value-type as
possible, going to write a follow-up email trying to draft/summarize why
I suggest after the call.
Svante Schubert: Andreas aske me to oversee a text proposal, too
Patrick: Move this discussion to mailing list - Andreas asks Svante to
write something up to see how it wroks
Svante Schubert: yes sure
Patrick: Office-4073 - Regina - there are general problems in vertical
relations and one is the term string - and we have vertical positions to
list and numbers - and there are character, text and line as reference
areas -
Patrick: Regina- what do applications differ between character, text and
line? any application with visual difference char, text and line?
Svante Schubert: @Patrick: Where should ODF implementers send to the
filled out template? You stated once an OASIS template of ODF 1.3
implementors:
https://lists.oasis-open.org/archives/office/202001/msg00008.html
Regina Henschel: 20.397 style:vertical-pos and 20.398 style:vertical-rel
Svante Schubert: Patrick: ODF TC member to the list, otherwise to the
tc-comment-list!
Svante Schubert: Patrick: we have to vote on the implementor, if we
agree on the implementation!
Patrick: Patrick - send implementation statement instruction to list



-- 
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: signature.asc
Description: OpenPGP digital signature