[Accessibility] Draft minutes for Accessibility Working Group Meeting February 4, 2004

Bill Haneman Bill.Haneman at Sun.COM
Mon Feb 16 10:46:16 PST 2004

Hi John/Sharon:

My comments for the Feb 4 meeting are inline:

John Goldthwaite wrote:

>Accessibility Working Group Meeting February 4, 2004
>Doug Beattie
>John Goldthwaite
>Bill Haneman
>Peter Korn
>Janina Sajka
>Gunnar Schmidt
>Matthew Wilcox
>Janina- check on a11y.org, calls to each member, talk to Mario about having
>discussion on Shared I/O on Feb. 11 also Michael Meeks  Michael at ximian.com
>Last weeks minutes approved as revised via email.
>Janina is work on calling everyone.  No news on licensing from U. Wisconsin.
>NSF has requested a formal proposal from us for the meeting.  We will work
>on this on the list this week and try to get it back to NSF next week.  This
>is good for two reasons. We need to have a meeting this year and we need the
>recognition that comes from having the funding from an agency like the NSF.
>The meeting will help us get broader participation.  Janina will post the
>letter and past documents on the website so we can discuss this.
>Janina hasn’t talked to Mario about meeting next week. Mario knows all the
>people and is capable to get into the code.
>Bill - the support for Braille-tty is an open issue.
Add "Current licensing of brailletty is a barrier to support and adoption."

>Janina-  Dave Melke co-maintainer of Braille-tty should be involved.
>Bill- Proposal- take AT_SPI subset.  

>It is now a set of API’s in Gnome.
"One layer, specified in Interface Definition Language (IDL), would be 
the best
candidate for standardization. The current ABI implementations of this
API (for which the IDL is the 'normative' specification) uses CORBA.
We have two existing implementations of this API/layer: one is
fully free (in C, under LGPL, with LGPL dependencies), and the other is
LGPL-licensed but requires a recent Java virtual machine and thus has
a dependency that is not fully 'free'."

> (IDL definition interface definition language) 

>CORBA defined that would be a candidate for a standard.  One implementation
>is fully free and has no dependencies.  The other is JAVA ….

>Peter- Open
? [omit]

>Bill- from the point of view of AT, it’s the AT layer that’s the most
>important to standardize.  IDL is a generic method for describing an
>interface without resorting to a programming language.  
"CORBA is the best-known back-end for IDL, and at-spi's IDL conforms to the CORBA standard.
There are multiple existing software systems that can parse IDL
and turn it into code. [including the FOSS ORBit2]."

>Janina- is i18n using IDL as a mechanism for internationalization?
>Doug- No, we can talk to them about it.  They also meet on Wednesday 2 hours
>before our meeting
>Bill- IDL itself does not have any direct international influence.  You have
>to think about which parameters in the interface need to be localized.  It
>would make sense for the international groups to have a look at any
>standards.   Likewise, we should be looking at what they are doing.
>Janina- this was mentioned at the FSG meeting.
>Bill – we’re talking about an interface that is seen by the AT and is
>exported by the OS.  The best candidate is a layer that is defined in IDL.
>This means it is not specific to a programming language and is leveraging
>the CORBA standards.  It is also a good candidate for migration to other
>implementations.  We could put it forward as a binary standard but could
>also allow other alternate non-binary standards, [for instance] if we needed to do
[see edit above]

>something for embedded Linux which does have all the things that are in the
>desktop version.  It wouldn’t be the same binary but it would be straight
>forward so that the same assistive technology could run with it without

>Janina – who’s standards are CORBA and IDL?
>Bill- Common object request broker architecture (CORBA) - OMG- Object
>management group.  Implementations of CORBA exist under all kinds of
>This layer has been implemented in C for the Gnome project and in Java as
>part of the bridge in the AT-SPI project.
>Question whether we want to do an API or ABI
>Gunnar- KDE will use a bridge from the Q-accessibility framework, so that’s
>no problem.  The only problem is that CORBA is not liked by KDE programmers.
>Using CORBA for inter-process communication for KDE [is likely to meet resistance]
>Bill- we need an interface that is not specific to a platform.  I don’t
>think we have another good candidate.  From the point of applications, the
>programmers would not have any direct contact with this.  Developers of AT
>would be using an API based on CORBA.  Depending on the language you’re
>programming in, CORBA maybe obvious or pretty well hidden.  Its messy in C,
>but better in C++.  For AT you need rich inter-process communications.
>Gunnar is making a good point, if we have a binary standard, it will be
>based on CORBA.
>Doug- we’re about a binary standard that can be validated.
>Bill- there …
>Doug- you’re saying nothing else exists?
>Bill- yes, the
>Peter – Its worth exploring the other alternatives, e.g. DBUS
>Bill- they are not rich enough, they don’t provide enough facilities for
>inter-process communication.  There is not an object oriented DBUS…
>Gunnar- currently KDE uses DCOP.  It is planned to use DBUS in the future.
>Peter- is it anticipated that DBUS will be enriched for IPC?
>Bill- DCOP is limited, and 'MCOP' which is somewhat richer for
expressing object-oriented APIs, has seen very limited adoption and is still
poorly matched to our needs.

> …. None of these other products support
>inheritance, overriding of behaviors, etc…

>Doug- with LSB 2.0 a major portion is the addition of C++
>Bill- that may argue more for CORBA since there is a good interface to CORBA
>in C++.  But that’s a language we need a ...

>The only other possibility is JAVA-RMI.  
[I note that this is not free, therefore not a candidate.]


>CORBA allows Java, Python, C++ and
>other libraries to communicate seamlessly with each other.
>You are saying that particular CORBA services are available to the language
>and libraries.
>Doug- pass it by …

>You’ve got in process calls for ABI, you have binary standards for FTP, DNS,
>Sockets. We’re proposing an ABI standard that has all the features of API
>accessible via IPC.
>>From the point of view of the application, the fact that its based on CORBA
>is not important, it’s the services that are available.
>Bill - At the layer we’re validating
>Doug- we’ve been standardizing at the level the application are running
>Bill- that’s not the layer where interoperability needs to be preserved.  It
>’s at the IPC level that we need to standardized
>… AT vs. application … we’re

> we’ve got applications written via different libraries all of which
>we are trying to make accessible.  All can’t link to the same library.  What is
>being proposed for standardizing is the IPC.  Whatever library is used, it
>needs to use the lower level of IPC to talk to the AT.   It’s far richer
>that things like XML-RPC….

>Janina- we also have to look at the SPI [I don't know what this was about - wph]…. Running out of time for today.
>We need to get Michael in next week.  Are there other people from KDE that
>need to discuss this?   If DBUS is not ready to provide this kind of

>- there are two ways of viewing IDL – object-methods interface and
>generator of code via parser.
>Matthew- will talk to some of folks and try to get them on the next call.

>Peter- focus on the information that has to be exposed for the application
>to be accessible.  This is a large stack.  First think about information
>that every application needs to expose to support accessibility. ..
>Parent-child relationships …
>Bill- we don’t want to get into that next.  focus on the AT first.  This a
>description of the types of services required by AT clients.
>We want to go toward an ABI, there is
>the API, and there is also a specific implementation ABI that can be tested against.  There could be other
>ABI implementations for the API, in which case we might have parallel, or complementary

>What I’m taking about is – from the point of view of the AT.  If you start
>talking about the applications, it can be confusing.  We need to look at one
>side first.

>Peter- Look at the information the desktop must provide.

>Bill- we want to standardize on the information stream.  We’re not working
>on certifying applications for their compliance.
>Janina- we need to have this conversation with enough people to have the
>buy-in for the standards.

>[not Peter - I think it was Doug here:]- you have to be able to validate and verify.  It’s useful to
>distinguish between the API and ABI. 

> Often standards level some items
>undefined. You validate against the specific back-end [implementation which] we provide – if I write an assistive technology that runs on a
>conforming platform, it should be able to run on others.  What we’re
>certifying is that the desktop has a basic set of services that conform to a single client-side SPI
[Service Provider Interface]

>The advantage of doing the standardization at the IPC level is that all the
>languages and libraries can use it.

Thanks! Bill.

>John Goldthwaite
>Center for Assistive Technology and Environmental Access, Georgia Tech
>john.goldthwaite at catea.org
>Accessibility mailing list
>Accessibility at freestandards.org

More information about the Accessibility mailing list