Well, in part this relates somewhat to the point that David
Clark brought up today -- awareness and misinformation. Accessibility has a poor
history in both areas. So, I believe it would be a great service to the
community of ODF developers and implementers to produce a guide.
- Mike
From: Nathaniel S Borenstein
[mailto:]
Sent: Thursday, May 11, 2006 11:49
AM
To: Peter Korn
Cc: Florian Reuter;
; ;
; Richard Schwerdtfeger
Subject: Re:
[office-accessibility] Re: [office] Table support for OpenDocument
Presentations
We keep encountering this same
discussion, over and over, in minor variants. The more I see us work on
the spec, the more urgently I believe we need to produce a non-normative but
highly authoritative Guide for ODF Implementers.
If OASIS can have an ODF Adoption TC, I'm sure it could
also have an ODF Implementation TC devoted to producing such a guide. Or,
we could have an Implementation SC of the main TC, if we wanted to keep it more
closely aligned with the latest issues regarding the spec. We could even
have an Implementation SC of the Adoption TC, on the grounds that the
implementation advice is vital for adoption, but the technical content would be
so high that I think that would be a poor choice. As a last resort, we
could even do this from outside OASIS entirely, though I think that would be the
second to worst possible alternative. (The worst, of course, would be what
we are doing now: Nothing.)
At
least twice a month, I think, I have been seeing issues raised in either the TC
or SC that come down to "this isn't a spec issue, but it would be vital advice
to implementers." I think it's time to bite the bullet and make a plan to
produce such a guide. Any other thoughts? -- Nathaniel
Peter Korn
<>
Sent by:
05/10/2006 06:49 PM
To
Richard
Schwerdtfeger/Austin/IBM@IBMUS
cc
Florian Reuter
<>, ,
Subject
[office-accessibility]
Re: [office] Table support for OpenDocument
Presentations
Hi Rich,
I thought we'd discussed this - that these questions are
entirely part
of the user interface in presentations that wrap around the
ODF table
implementation.
I agree these are issues we have to work
out with the folks implementing
tables in presentations in our office
suites, but I don't see how that
impacts our XML encoding
decision.
Regards,
Peter Korn
Accessibility
Architect,
Sun Microsystems, Inc.
> When considering tables in
presentations please consider user agent
> issues.
>
> - Will
the table area be clipped and require scrolling. In MSOffice
> that does
not happen?
> - Has the group addressed all import/export issues?
>
- Will a frame be rendered in the user agent if it is embedded?
>
MSOffice does not. If we don't address this the layout will be a
mess?
>
> We also need to ensure the author has the ability to
define row and
> column headers as are defined in the table
construct.
>
> Rich
>
>
> Rich
Schwerdtfeger
> Distinguished Engineer, SWG Accessibility
Architect/Strategist
> Chair, IBM Accessibility Architecture Review
Board
> blog:
http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441
>
>
"Two roads diverged in a wood, and I -
> I took the one less traveled by,
and that has made all the
> difference.", Frost
>
> Inactive
hide details for Florian Reuter
> <>Florian
Reuter <>
>
>
>
*Florian
Reuter <>*
>
>
05/09/2006 02:17
AM
>
>
>
> To
>
> ,
>
> cc
>
>
>
Subject
>
> [office] Table support for OpenDocument
Presentations
>
>
>
>
> Hi,
>
> I just want to give a
brief status description of the evaluation of the
> table support for
OpenDocument presentations.
>
> Currently I see three different ways
of adding table support to
> OpenDocument specifications:
> a)
"native" table support
> b) Embedded object based table support
> c)
tables in text boxes
> d) Drawing object plus annotation based table
support
>
> ad a)
> The "native" table support would have the
advantage, that tables are
> "first-class citizens" of OpenDocument
presentations. An example would be:
> <draw:frame>
>
<table:table>
> ....
> </table:table>
>
</draw:frame>
> The above encoding is closest to Open XML and would
ensure rountrip.
> The disadvantage of the above solution is, that
currently deployed
> reader would ignore the <table:table> element
and thus tables where
> missing in the document. This would require all
vendors of OpenDocument
> processing applications to ship product
patches.
>
> ad b)
> Encoding tables in OpenDocument
presentations as "embedded objects"
> would be the best solution regarding
backward compatibility. Encoding as
> "embeeded object" means nothing else
than "use OpenDocument spreadsheet
> tables in presentations as embedded
objects". An example is:
> <draw:frame>
>
<draw:object xlink:href="javascript:void(0);"
> xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"
/>
> </draw:frame>
> The disadvantage of this solution is,
that tables in presentations are
> no longer "first-class citizens" as
they are e.g. in Open XML.
>
> ad c)
> OpenDocument allows in
its current version that tables can appear within
> text boxes. However
this currently not implemented in e.g.
> OpenOffice.org. For
example:
> <draw:frame>
> <draw:text-box>
>
<table:table>
> ..
> </table:table>
>
</draw:frame>
> Here without any schema change table in
presentations could be achieved.
>
> ad d) [suggested my Yue
MA]
> Currently OpenDocument processing entities store tables in
presentations
> as shapes, i.e. a table is "drawn", but the structure is
forgotten. By
> simply annotating this "drawn" tables with the table
structure
> information both backward compatibility as well as
accessibility needs
> could be satisfied.
> The disadvantage of this
is, that OpenDocument would get a rather
> "unconventional" second table
model.
>
> I would like to finish the investigation phase know and
start dicussing
> the prefered solution.
>
> Looking forward
for your comments.
>
> Best regards,
>
>
Florian
>
>
>
---------------------------------------------------------------------
> To
unsubscribe from this mail list, you must leave the OASIS TC that
>
generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
