F2F Day 1
Attendees
- Dave Pawson
- Peter Korn
- Janina Sajka
- Malte Timmerman
- Rich Schwerdtfeger
- Hironobu Takagawi
- Chieko Asakawa
Scribe(s): Dave Pawson
Agenda
Item. Table in presentation proposal
Item. What is left for DAISY support?
Item. Gap analysis - Chieko
1 Table in presentational proposal
DISCUSSION: PK. Email yesterday - from Florian.
- RS. Table draft 1 and 2 from Florian.
- MT. element in a frame or element inside group
object should be considered.
- 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 applications properly marked up. Star
office wants these to be live tables (e.g. connect to
databases). They don't think they can fix number 2 in ODF 1.1
timeframe. Hence Florian proposal is based around number 1.
This is backwards compatible with ODF 1.0 readers. By making
an OLE embedded link, we preserve the data format which is
easy to read for most applications. Then for 1.2 we solve the
table problem in a more 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 the XML specification, only adds a new reference
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 cannot have draw:group as a child. This is
a 1.2 proposal
- RS. Consider 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 selection of the proposals 1 and
2.
- RS. Group has accepted that Florians proposal 1, embed
a calc table inside a presentation frame is preferred over
proposal 2 (using group instead of frame).
- RS. AT cannot get at useful, local headers provided by
the author. This is an agenda item for tomorrow.
- CA. With this proposal we are compatible with MS. We could
consider joining the 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 the 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 presentation.
Action item: Propose wording change for 8.2.4, to add use case for
accessibility. Note: RS has edited version of spec. Will post
to the list ASAP
Who? RS
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 we should renumber. Could be an issue when
talking about page x, when read on different systems, this
could be different.
3 Keyboard issues
DISCUSSION: Slides presentation - Hiro. Issue. Specification doesn't define any
Z index usage.
- HT. Need to bring from specification into
implementations. CSS usage of Z index is negative, ODF has
non- negative values. We need to define in detail the Z
index.
- PK. Specification, page 283. Could be a copy/paste
error. Does not make sense. Could mean 'should use svg:z
index'.
- MT. Z index is never used. Content order can only be
changed by changing the 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.
The author specifies the order in which objects gain focus
(possibly using 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 specification version.
- PK. Can't do that due to backwards
compatibility issues.
- HT. Z order still very unclear. Agreed by all.
- HT. Could use definition of nav-order from CSS3 for
semantics and name.
- RS. Should be done on the 'draw:page' element for
impress and page anchored objects in calc (table:table) or
write (), as a 'nav-order' attribute, with a list of idrefs
which can be rearranged by a thoughtful user. ID values cannot
be removed (unless the object is removed). All focusable
drawing elements must be present within the list.
- PK. For any application, the element has to be on a user
conceptual page. For calc this is table:table, for impress it
is draw:page, for a drawing, draw:page. For writer, we want it
on office:body, i.e. the whole document! This makes sense with
the other navigation in a document. The challenge is, I can insert
a table and that table could have associated graphics.
- DP. Can we navigate the alternative view (graphical
items or objects) in a document just as we do with impress
drawing objects. Means all tables should be navigable in the
same way (no difference between embedded or natural). Then
navigation could recurse as needed.
- PK. Can an author omit an object? Agreed no.
- PK. Default lazy initial tab order is document
order. When the nav-order attribute is not present a user
agenst should create the tab order in the following manner,
based on document order. This is done when an author starts to
modify the tab order (and not before). This is done since
nav-order is not needed by default. If it is put in too early
then there is no way to distinguish navigation order as being
purposefully set as apposed to not.
- CA. We have received much feedback that the IE table model
is very good for navigation.
- PK. The user needs to discover objects on the page. A
key could say 'describe my surroundings'. Informs the user
about non text objects. Or she can tab through them. If we
want a thoughtful author to specify a navigation order, User
Agent could decide it?
- DP. Suggest that navigation order should be at top
level only, not including objects at a lower hiearchical level.
Action item: Produce specification change proposal based on these
minutes
Who? Group
Due date: By Sunday night if possible
4 Gap analysis
DISCUSSION: Deferred to the morning, though the link issue is now
resolved.
Summary of Actions
- RS
-
Action item: Propose wording change for 8.2.4, to add use case for
accessibility. Note: RS has edited version of spec. Will post
to the list ASAP
Due date: By Sunday night (PK)
- Group
-
Action item: Produce specification change proposal based on these
minutes
Due date: By Sunday night if possible
|
Date: 2006-05-20T09:25:17Z
Time:
Venue: RNIB Edinburgh
Date: 2006-05-20T15:21:31Z
Version: 1 Date: 2006-05-22T10:50:13Z
Version: 1