OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ODF chat log - 24 July 2017


Greetings!

Our chat log from today's teleconference:

anonymous morphed into Jos van den Oever
Jos van den Oever: unf i cannot join via audio because i am at a conference
Patrick: Jos, ok, will mark you as 2/3 present ;-)
Jos van den Oever: Patrick :-)
Patrick: quorum, yes
Patrick: I'm unhappy with the current work flow. Continuing the current
way, we will never get a version ODF1.3.

We need editorial drafts of the four parts and of the schema
immediately. We have already made decisions to a lot of issues. Those
should be applied now. Of cause we can add further issue solutions later
on. But we need intermediate documents, so that at one point we can say,
break here and make this to ODF 1.3.

What is needed that this can happen?

Who has the technical and linguistic skills and enough time for it?

Do we need some monetary support?
Jos van den Oever: i agree with the sentiment
Jos van den Oever: it's time to work on the revised text
Patrick: +1
Andreas J Guelzow: +1
Patrick: Michael - blocked on implementations on change tracking - 1
implementation by a non-member of the TC
Patrick: need several implementations to build a standard of
interoperability \
Patrick: ask Svante about OpenExchange
Jos van den Oever: for 1.3 we could fix the pressing issues in change
tracking instead of having a complete new part of the spec
Jos van den Oever: e.g. state that change tracking on table is possible
for all formats and not just spreadsheets
Jos van den Oever: that's a one-line change
Patrick: Jos - was that what prevented MS from implementing ODF change
tracking
Patrick: Aarti - will ask what stopped MS from using ODF change tracking
Jos van den Oever: no, their choice not to implement change tracking not
not technical i think
Jos van den Oever: but the change tracking on tables certainly is important
Patrick: Jos Aarti will check to see
Patrick: yes to change tracking on tables
Patrick: Michael, need to have more detailed agendas with issues for the
meeting ahead of time, to allow for meeting preparation
Michael Stahl:
https://issues.oasis-open.org/browse/OFFICE/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
Patrick: Michael - start meeting with this URL
Jos van den Oever: +1
Patrick: Process issues in this list
Patrick: focuses on issues where people have recent context
Patrick: Regina - need to put all the things we have already together -
possible to seek funding if we know how much work is needed
Regina Henschel: Please add it to mail, if you can estimate it. We can
not solve it here immediately.
Patrick: sure
Regina Henschel: We should now look at
https://issues.oasis-open.org/browse/OFFICE-2122. That has got some
discussions last week.
Patrick: <define name="draw-g">
<element name="draw:g">
<ref name="draw-g-attlist"/>
<ref name="common-draw-z-index-attlist"/>
<ref name="common-draw-name-attlist"/>
<ref name="common-draw-id-attlist"/>
<ref name="common-draw-style-name-attlist"/>
<ref name="common-text-spreadsheet-shape-attlist"/>
<ref name="common-draw-caption-id-attlist"/>
<optional>
<ref name="svg-title"/>
</optional>
<optional>
<ref name="svg-desc"/>
</optional>
<optional>
<ref name="office-event-listeners"/>
</optional>
<zeroOrMore>
<ref name="draw-glue-point"/>
</zeroOrMore>
<zeroOrMore>
<ref name="shape"/>

</zeroOrMore>
</element>
</define>
Patrick: LO uses document order inside draw:g
Regina Henschel: Are there exists applications which currently use the
z-index attribute for the child element of a <draw:g> ?
Patrick: If not, then can lose: If producers generate a *draw:z-index*
for a shape that is a child of a <draw:g> element, the value for the
child shape should be larger than the value of the *draw:z-index* of the
<draw:g> element and smaller than the value of the "draw:z-index* of any
shape that is both either a sibling of the <draw:g> element or a sibling
of a <draw:g> ancestor of the <draw:g> element or a top-level shape, and
also has a larger *draw:z-index* value than the <draw:g> element.
Patrick: then, Producers should not generate a *draw:z-index* becomes
Producers SHALL NOT generate...
Michael Stahl: +1
Patrick: Agreed, resolution in JIRA.

**********

Hope everyone is at the start of 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 


Attachment: signature.asc
Description: OpenPGP digital signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]