Note: These minutes have not yet been finalized.
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
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
Note: These minutes have not yet been finalized.
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?
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
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
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)
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 email@example.com
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
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)
JS: may or may not meet in the first week of July; might be second