From The Linux Foundation
Revision as of 23:34, 11 June 2008 by Oedipus (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Open A11y Working Group Conference Call (3 June 2008)

Note: These minutes have not yet been finalized.


  • Janina Sajka (JS/chair)
    • Stew Benedict (SB)
    • Pete Brunet (PB)
    • Mark Doffman (MD)
    • Mike Gorse (MG)
    • Brian Merrell (BM)
    • Gregory J. Rosmaita (GJR/scribe)
    • Gunnar Schmi-DT (GS)
    • Olaf Schmidt (OS)
    • Andreas (Novell)
    • Willie Walker (WW)
      • regrets: none logged


JS: welcome Andreas - glad to have you in the group; welcome back Brian

GS: KDE Accessibility; recently finished diploma thesis - screen magnifier for minutes

OS: work on KDE Accessibility as well

MD: working with Mike Gorse on mono port

PB: chair of IAccessible2 group; work in accessibility architecture at IBM

SB: Linux Standard Base

WW: Willie Walker; lead of Orca project at GNOME

Andreas: based in Spain; work for Novell; involved in mono community - open source contributor for years; now on accessibility project; want to attend calls to listen, learn and participate

JS: delighted to welcome you -- is this your first experience with engineering accessibility?

Andreas: yes, my first

JS: you've come to the graduate course for starters

For Reference

Preliminary Items

Approval of Past Minutes

Meeting Minutes

Note: These minutes have not yet been finalized.

Topic 1: AT-SPI Testing in LSB / Porting Strategies for D-Bus

JS: MarkD sent email to list outlining a plan for AT-SPI testing in LSB and PeteB has announcement about IAccessible2

JS: Mark, from your email it sounds like a 2 part approach

MD: LSB standardizing of AT-SPI library to ensure ATs work across distributions; written a wiki article on LSB wiki - 1 major point of uncertainty: what should we be standardizing for for AT-SPI? there is an IDL for AT-SPI, but there is also pyatspi -- definition of library interfaces -- pyatspi documentation probably need to be created based on IDL

MD: second: implementations: OpenOffice, java, QT implementations; put together tests to investigate all implementations

MD: hope will have better idea how long it will take to develop and test - not as long as ATK tests or same amount of time

SB: massaged into packaging

MD: have to classify IDL refs

SB: standard LSB model: user interface, normal parameters (pass or return unexpected thing)

MD: have to write test applications, widget toolkit, and tests for pyatspi; most tests for pyatspi and some "shallow" tests for cspy to ensure interoperability

SB: semi-automated tools -- basic generation testing

MD: TTC stuff, right?

SB: right

MD: not sure TTC will be that useful - XML and C tests - pyatspi

SB: work with the Russian team

MD: any opinion on how useful to have pyatspi and cspy?

WW: having standard for pyatspi great; not sure if has to be at LSB level; help bring KDE and others together through LSB

MD: think will be useful for work on D-Bus -- at moment IDL-based; suite of tests for libraries that ATs actually use and a standardized, well-documented interface, then don't need to worry about IDL but can concentrate on interfaces remaining constant

JS: IDL to XML as move to D-Bus?

MD: Michael Meeks against using IDL to XML: mainly because there isn't an XML schema or language for describing object oriented interface - lots around, but not one currently that is standard component object description language; can translate IDL by hand into D-Bus -- IDL is automatically translated to language binding or pyatspi - in future, IDL can still serve as description of what language should have; pyatspi not an exact corba translation, but pretty close

MG: XML would need to be maintained in parallel with IDL -- long term implications? need to identify good standard in XML

MD: important point is standardizing around pyatspi and cspy based on documentation for LSB

WW: good point; change for performance reasons might cause complications

MD: ok for serving as basis for libraries - description of end-user interface

JS: high-level description of the interface useful to standardize upon - can then move with code as develops without description changing too much - if in d-bus environment, perhaps an IDL standard is ok

MD: pyatspi and cspy shifted slightly from corba IDL interface -- how close is it to IDL is one focus; if have tests, can move forward on transport and interface mechanisms

WW: XML descriptions too difficult and hard to parse, whereas IDL easier to read?

MD: IDL goes further in describing pyatspi - pyatspi has little documentation, but can use IDL to describe pyatspi; XML i put together derived from IDL but should exist independently - describes transportation but not language interface

PB: IDL live on as documentation tool?

MD: may not - may simply serve as basis for pyatspi and cspy interfaces or may want to keep it since pyatspi and cspy have to follow IDL - needs to be retained as a tool for other accessibility interfaces

MD: if added something new to IDL, changes have to be made to d-bus xml, the java language -- won't happen automatically; could do away with IDL and standardize around pyatspi or cspy, or can retain IDL

MG: sense to standardize language bindings rather than IDL?

PB: interface definition language - used by corba to describe object model and calls one can make on objects

JS: closer to verbal description of what is going on, but is strict enough to be machine parseable

MG: convert IDL into python bindings - language agnostic way of describing service

SB: specifying interfaces would fit into model LSB using so far, but could do something with IDL

MG: specific rather than generic or generic rather than specific

SB: language bindings more appropriate - as LSB goes further up stack, varying from original model; flexibility in what LSB can do -- whatever open A11y feels most appropriate

WW: IDL as documentation tool, hard to keep IDL and XML in sync - can XML produce document or machine parseable only?

MD: XML that we have doesn't produce decent documentation now, but with some work (XSLT) can get documentation; could standardize on XML and write tools to get documentation from it for standard tests

SB: differences between d-bus xml and interfaces; getTreeFunction in d-bus XML allows getParent getChildren without going over the bus

MD: that is Michael Meeks point - methods in XML that don't translate into pyatspi or cspy

SB: could have XML tag "this function should be included in implementation, but not necessarily in IPC

PB: think of SIP - defined by RFC (32 or 61) -- talks about bits going over the wire -- how bits get delivered, so XML should be analogous to that: define transport, which bits to transport; C library for SIP could potentially be a library for SIP; 2 standardization spaces - protocol over the wire and other language bindings -- both make sense, one more than other?

SB: LSB model is make distributions and ISBs

JS: do we need to take high-level description into LSB? can make Open A11y standard - could even take to ISO and simultaneously test so have standards based on language bindings based on LSB -- if we do take 2 pronged approach, (a) would be useful and (b) both don't need to be specifically LSB

MD: XML description the low-level description - standardize by versioning; tests for transport protocols have to be documented but not in LSB; IDL standardized by pyatspi interfaces

SB: makes sense: keep XML as standard description (protocol for communication); standardize language bindings in LSB

MD: sounds right to me

JS: could be Open A11y standards

MG: if standardize d-bus implementation, have to consider cost -- need to get something tested for performance first

JS: just want overview of how to fit together

MD: getting documentation up to scratch and starting tests can be done now; interfaces shouldn't change

SB: don't have to take whole set of interfaces - if certain are stable and not going to be changed, could then issue a sub-set

MD: right

GS: sounds sensible to me

OS: important to have flexibility to have look at which kind of communication works best performance wise on d-bus; don't want API for ATs to change; check that is ok to standardize that before proceeding further a good idea and reality check

JS: in addition to writing tests, want to ensure have good documentation in good XML

MD: pyatspi and cspy interfaces shouldn't be a problem - documentation complete for cspy - for pyatspi, not as much documentation, just what is implied in IDL; standardizing XML a different issue farther out on the horizon; should talk to other d-bus groups, too

JS: some documentation work now to explain pyatspi

WW: going to be troublesome - pyatspi just sucks out IDL - behavior sparse, lots of code with python magic included

JS: leave IDL or spin off IDL for now - not standardizing (at least not yet); binding language and testing

WW: not sure that all the magic will survive d-bus

MD: will require a lot more hand coding is my guess

JS: direction for now: tests

MD: number of tracks: MikeG and i will look at form XML will take; work on pyatspi on d-bus will pay attention to documentation; if anyone has time or will to start LSB tests for cspy and pyatspi, that would be critical

JS: valuable now and as move from corba to d-bus

(no disagreement)

MD: pyatspi tests - standardize and use in LSB

JS: estimates on time involved in doing that work to put proposal together to find someone to do it

MD: will ask around and let Open A11y know timeframe

MG: probably same amount of time to write ATK tests, but not sure yet

SB: George Kraft IV may have some ideas on prototyped tests

JS: are coming to convergence on how to proceed; finally talked through issues to reach level of agreement so can move process ahead

JS: thanks mark

PB: FYI - if on call without a mute, should be able to toggle mute on and off using *6 (star/asterisk 6)

Topic 2: IAccessible2 Ready for Review by Community

PB: last 6 months been upgrading IAccessible2 documentation -- first step was getting the IDL correct; 80 issues addressed in new documentation; at a point where can do an official RFC - filled out form from JS to redistribute to other groups; wrong end date - should be end of june

PB: will be forwarding RFC request to the IAccessible2 list, the main Open Accessibility list, the NVDA list, the blind-programming list, Freedome Scientific, GW-Micro, Dolphin Access, AIA, Mozilla, Adobe, and others -- suggestions?

JS: is there still a Section 508 list?

PB: will investigate

BM: OpenOffice list?

PB: will send notice to maintainers

GJR: will forward to

JS: comments in a broader context - perhaps the WG should ask Amanda McPherson (press person from LF)

PB: good idea -- workgroup members can review the latest draft specification by following the links from the IAccissible2 main page

GJR: needs to review HTML for compliance with Open A11y publication standards; technological and health problems have precluded my review, but it is at the very top of all my ToDo lists

PB: LGPL license for IDL still needs discussion/investigation

JS: GJR and I should be receiving word from the LF heirarchy soon

GJR: LF policy mandates use of GNU General Public License, Version 2 if issuing software or libraries

PB: IA2 SIG meets in an hour

New Business

Identify Topics for the 10 June 2008 Teleconference

JS: return to the d-bus port and testing topic next week? time estimates on moving towards proposal for a granter

MD: might have brief report next week (June 10)


  • no meeting 17 June 2008
  • no meeting 24 June 2008

JS: may or may not meet in the first week of July; might be second

Wrap Up

Summary of New Action Items

Summary of Continued Action Items

Summary of Resolutions