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

Bill Haneman Bill.Haneman at Sun.COM
Thu Feb 5 08:55:21 PST 2004

Ah, I'd like to propose some corrections to the minutes.  There was some 
fairly involved discussion, and though John did a good job keeping up 
with the convoluted discussion, there are points that need a bit of 
editing I think.

Not sure I'll get them today, but by tomorrow...


- Bill

Sharon D Snider wrote:

> The meeting minutes have been posted. Also, I have finished the 
> Meeting minutes archive.
> Sorry, I missed the meeting. I listened to music for about 10-15 
> minutes before I hung up.
> Regards,
> Sharon Snider
> IBM Linux Technology Center
> (512) 838-4127, T/L 678-4127
> "John Goldthwaite" <john.goldthwaite at catea.org>
>                         *"John Goldthwaite" <john.goldthwaite at catea.org>*
>                         Sent by: accessibility-bounces at freestandards.org
>                         02/04/2004 02:44 PM
>                         Please respond to john.goldthwaite
> To: "0 Accessibility Linux List" <accessibility at freestandards.org>
> cc:
> Subject: [Accessibility] Draft minutes for Accessibility Working Group 
> Meeting February 4, 2004
> 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.
> 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.
> There is a layer (IDL definition interface definition language) that is
> 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
> 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. The is a particular
> one CORBA that is used for There is existing software that can parse IDL
> and turn it into code.
> 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. If we needed to do
> 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
> modification.
> 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
> licenses.
> 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 …
> 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, they are thinking of creating MCOP which would 
> allow
> richer object oriented processes. …. None of these other products support
> inheritance, overriding of behaviors, …
> 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 
> in C++. But that’s a language we need a ..
> The only other possibility is JAVA-RBI. 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 
> 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 
> is not important, it’s the services that are available.
> Matthew-
> 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
> Peter- we’ve got applications written via different libraries all of which
> we are trying to make accessible. All can’t link to the same …. 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 HPG….
> Janina- we also have to look at the SPI …. 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
> behavior
> Peter- 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… We want to go toward an ABI, 
> there is
> the API, there is an ABI that can be tested against. There could be other
> ABI implementations for the API ….
> 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.
> Peter- 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 …
> Bill- 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 the
> The advantage of doing the standardization at the IPC level is that 
> all the
> languages and libraries can use it.
> John Goldthwaite
> Center for Assistive Technology and Environmental Access, Georgia Tech
> john.goldthwaite at catea.org
> _______________________________________________
> Accessibility mailing list
> Accessibility at freestandards.org
> http://www.freestandards.org/cgi-bin/mailman/listinfo/accessibility
>Accessibility mailing list
>Accessibility at freestandards.org

More information about the Accessibility mailing list