early minutes, day 1

1 Table in presentational proposal

DISCUSSION: PK. Email yesterday - from Florian.

RS. Table draft 1 and 2.
MT. element in frame or element inside group object.
PK. 1. MS office and Powerpoint can create tables. Import needs to provide access. None of todays products generate tables naturally. 2. We want to be able to create tables in ODF apps properly marked up. Star office wants these to be live tables (e.g. connect to db's). They don't think they can fix 2 in odf 1.1 timeframe. Hence Florian proposal is around 1. Is backwards compatible with 1.0 readers. Make an OLE embedded link, we preserve the data format which is easy to read. Then for 1.2 we solve the table problem in general way, i.e. make them a full suite of elements. Look at suggested XML to see how hard it is.
RS. Looking at first document. 9.3 in florians document. This is XML spec, only adds a new ref name table-table.
PK. Example 3 col 4 row table. Table read off by row.
RS. This converts to table format, not ole embedded.
MT. This is what we would like, but I don't see backwards compatibility.
RS. Could be that for 1.0 readers, have embedded OLE, for newer readers, has the actual table.
PK. No comparison - pros and cons of the two proposals.
MT. Proposal to have it in a frame or in a draw:group. Better in frame than group. Replacement can only be OLE. Draw:frame cannont have draw:group as a child. This is a 1.2 proposal
RS. A slide with a table. Embed an OLE object that renders the table. The AT has to go to a different API to get to it.
MT. They have this already (access to embedded OLE objects)
RS. Have a embedded calc spreadsheet.
MT. Prefer 1 from Accessibility viewpoint. Not mandatory to create the parallel object element, only recommended for backwards compatibility. Hiearchy is frame, table and object as children.
DP. Summary. Spreading discussions to the Mass case, how AT accesses headers in a table in a presentation. This can be separated from the selction of the proposals 1 and 2.
RS. Group has accepted that Florians proposal 1, embed an calc table inside a presentation frame is preferred over propsal 2 (group instead of frame).
RS. At cannot get at useful, local headers provided by the author. An agenda item for tomorrow.
CA. With this proposal we are compatible with MS. Could consider joining metadata sub committee.
RS. Found a problem with way we deal with tables in writer. When we want a header in a table, I get a row header element, others I just use style to make it look right, but lose semantics. This is Pete Bournets issue.
PK. Would like to defer this to day 2. Under directions for authors and implementors.
RS. Examples on screen. Shows that spec is presentation oriented. Spec allows no headers. so ODF doesn't tag it as a header unless needed for prese.

Action item: Propose wording change for 8.2.4, to add use case for accessibility.

Who?

Due date: By Sunday night (PK)

2 Daisy

DISCUSSION: bg. DaveP. Described different types of DAISY book. Explained Daisy versions.

PK. Need a down conversion to 2.02 for common
MT. Pagenumbers are layout based. Can cause problems.
DP. Need both soft and hard page breaks.
PK. We provide list of requirements and annotation, suggested draft markup for each.
DP. Suggest pagebreak, attribute soft or hard.
MT. We have hard page break, just need soft.
RS. Requirement. Add soft break to spec. Also need UAs to deal with the soft page break. Do same page layout for different appliation.
PK. When to change page layout. At save time, dialogue could ask if renumber. Could be an issue when talking about page x, when read on different systems.

3 Keyboard issues

DISCUSSION: Slides presentation - Hiro. Issue. Spec doesn't define any Z index usage.

HT. Need to bring from spec into implementations. CSS usage of Z index is neg, ODF has non negative values. We need to define in detail the Z index.
PK. Page 283. Could be copy/paste error. Does not make sense. Could mean 'should use svg:z index'.
MT. Z index never used. Content order can only be changed by changing z order
PK. No reason for user to care about document order and its relationship to Z order. Except for 'additional meaning'.
MT. Z order is presentational, not tab order.
MT. In Star office, changing Z index affects tab order.
RS. Must provide a means of specifying a 'thoughtful order', which should take precedence over default tab order. Author specifies the order in which objects gain focus (possibly id value). Order must be editable. Scope within a single slide (or drawing object within spreadsheet sheet). Not for writer drawings. Default setup is document order, changed by the author of the document.
HT. My proposal did not impact schema etc, this could be for a later spec version.
PK. Can't do that due to backwards compatibility.
HT. Z order still unclear. Agreed.
HT. Could use definition of nav-index from CSS3 for semantics and name.
RS. Should be done on the 'draw:page' element for impress and draw:z in calc, as a 'nav-index' attribute, with a list of idrefs which can be rearranged by a thoughtful user. id values cannot be removed. All focusable drawing elements must be present within the list.
PK. Can an author omit an object? Agreed no.
PK. Default lazy initial tab order is document order. When the nav-order not present user agenst shall create the tab order in the following manner, based on document order. This is done when an author start to modify the tab order. This is done since not needed as default. If put in early then there is no way to distinguish it as being purposefully set as apposed to not.

office-accessibility message

F2F Day 1

Attendees

Agenda

1 Table in presentational proposal

2 Daisy

3 Keyboard issues

Summary of Actions