[Accessibility] Draft meeting minutes- Feb. 25, 2004

[Doug Beattie]

A few corrections: (See below)

On Wed, Feb 25, 2004 at 03:37:10PM -0500, John Goldthwaite wrote:
> This isn't as bad as the last couple but perhaps Bill and Doug should check
> it over before we post it.
> 
> Accessibility Working Group Meeting February 25, 2004
> 
> Doug Beattie
> John Goldthwaite
> Bill Haneman
> Peter Korn
> Janina Sajka
> Gunnar Schmidt
> Matthew Wilcox
> 
> Last weeks minutes need to be reviewed.
> Action items-
> 
> Today- step back from Bill’s explanation of AT-SPI and see what we need to
> do in the other areas.  We had good questions from members and from Stuart
> Anderson on the details.  There will likely need to be more discussion.  How
> do we get towards consensus?  This may be somewhat different from what LSB
> is used to seeing as a standard.  Other than explaining over and over again
> to wider audiences, what can we do?
> Bill – if we could summarize the goals and issues that have been raised. We
> have it in a narrative form that might be hard to decipher.  If we can state
> the goals, the requirements that have come out of the conversation.
> Janina- FAQs?
> Bill- more like bullet points and a few paragraphs.  The discussion
> presupposes some things we’d like to do, we need to flesh those out more
> explicitly.  We expressed a desire to have a product that’s not tied to a
> specific implementation or to a particular language.
> Janina- it shouldn’t be hard to start this discussion on the list.  Other
> thoughts?  Do we need to figure out when we need to do a face to face with
> other people, such as at Linux World in San Francisco?
> Bill- when is it?
> Doug- around the first week in August.
> Janina- are you likely to be there, Bill?
> Bill- August is usually a bit dicey.  ..
> Janina 
 FAQ
> Bill- I wasn’t thinking FAQ but that may be what we need.  I was thinking of
> characteristics of the standard.  If we put this in the terms of
> requirements, we may find we can’t meet our requirements for this year.  If
> it has 
 validatible, implementable for various toolkits, not just one
> toolkit.  The best solution may be more that one ABI or API. Because this is
> a pretty complex item, it has elements that are in several parts of the
> desktop so we may need more than one ABI.
> Janina-  Requiring CORBA seems to raise questions for some people, we need
> to explain why this is the right answer.  If there are other solutions,
> perhaps someone could come up with a solution.
> Bill- We need an implementation that can have components that can replaced
> without redoing others.  Every standard does tye in,  if you have a
> requirement for C in your environment, that will determine some aspects of
> the linking loader, bindings, 

> Doug- for every version that the LSB does, they get down to the lower levels
> such as linking libraries.  They get down to that level.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
such as specific symbol versioning on the libraries.
> ?
> Doug- that’s not tying to an implementation, just to use commonly used
> libraries.
> Bill-   there is an element of implementation in the spec.  You are saying I
> ’m going to communicate in a certain way.
> Doug- that’s correct. 
 C library 
  It’s best common practice.
> Bill-  
 CORBA had a long soak time.
> Doug- you’re going to see how it’s going to work well and be fair and
> equitable for everybody.

Main point above was we need to make sure it works appropriately and is
fair and equitable for everyone to use.

> Janina- this is the question – is it functional for the greatest number of
> people and doesn’t break features.
> Doug- and it’s not going to cost them anything as far as royalties.  If it’s
> the best thing technologically, why wouldn’t people want to do it?
> Bill- we’re providing sources, it’s just a question dropping them in.
> Doug- having them know that the upstream providers are going to be around,
> so that the features are going to be there without them having to redo it

 having others (distros and ISV) know that the upstream providers are
going to be around so the features will be maintained with our group or
the distros and ISV having to maintain the item(s).

> themselves.  For example, xfree86 changed its license and now most people

                                                                     distros

> are going to drop it unless they change the license.  A new source is going

  may drop using the newer versions unless XFree86 changes the new license.

> to have to be adapted to keep the licenses compatible.  There should be
  ^^            ^^^^^^
  may           adopted

> multiple things from which to choose from.
> 
> Janina- seems like writing it up in plain English is the next step.
> Doug – I still want to be clear that CORBA is the right thing to do, its not
> going to lock us in.
> Bill- we have implementations of CORBA ..  there doesn’t seem to be any
> problem with having a free, open source implementation.  Commercial
> implementations have existed for years, although it’s not as commonly used
> now because of SOAP and XML.  If it’s a question of whether CORBA will be
> around, the answer is yes.
> Doug
 copyright?

  What about copyright issue?

> Bill- yes the copyright is open source.  A lot of open source software
> relies on the CORBA standard, so we won’t be alone. It makes me confident
> that other people have addressed this question and found that there is not a
> problem with CORBA.
> Use of CORBA is specific to a implementation of an IDL. But the IDL is
> expressible in other ways.  If we want to change the ABI we can do that
> without disrupting the API’s.  We can swap in an alternate ABI that have the
> same semantics and be transparent.
> Doug- ..
> Bill- worst case you’d have to recompile your test suite.
> Doug-

We don't want to have to deliever any new binaries to make things work.
The discussion/question here, from myself, was that we do need to somehow
guarantee that an ISV can write an application and the binary will run
in the same manner on all certified distributions claiming to support
the standard. The FSG is concerned about making life between ISVs and
distributions compatible.

> Bill- didn’t say binary because that’s ABI.  When we’re talking ABI its 

> Doug- when I’m talking ABI it’s an application running without problems.
> Bill- it’s a slightly different point.  With IDL, we can swap
> implementations without breaking the clients.  The ABI will change but the
> semantics as seen by the application won’t change.  We may have to recompile
> the test suites.  There may be a time in the future where we have a binary
> incompatibility such as major version change.  A new technology may come
> along that we want to swap for CORBA.  
 The implementation details have to
> be shared across the desktop.  The important.. is not at the bindings, its
> at the interprocess communications level.  Making changes means making
> changes to the protocols.  We’d have to change the tests.  If we test just
> one side of the equation, that’s not an adequate assurance that something
> such a screenreader will run.  If we standardize at the language bindings,
> we could swap 

> Doug- it sounds like we need to standardize a several levels
> Bill- Yes
 we could confirm that the interfaces are there.  On the client
> side we could test the ABI so that the client wouldn’t have to be
> recompiled.  The downside- the C bindings would be a wrapper around
> something that’s already a wrapper.  If we standardize on the protocol,
> because CORBA provides a definitive spec about what a client binding is
> supposed to look like, the CORBA binding is not as implementation
> independent as we’d like.  It would have some ‘warts’, if we change the
> implementation we’d have to make the new software compatible with the ‘warts
> ’.  The application would have to think it was talking to the CORBA server.
> 
> Janina- lets back up to the face to face meeting.  Do Gunnar or Matthew have
> any questions?
> Gunnar- I don’t have anything to add right now.
> 
> Doug – Linux World is Aug 2-6, perhaps earlier at ?

                                                  in San Fransico

> Janina- Bill, where are you likely to be over the next year-
> Bill- probably, Gnome Users and Developers European Conference (GUDEC)
> Matthew- Linux symposium.org is July 21-24 in Ottawa; I’m on the review
> committee for papers.
> Doug- many of the LSB people will be there. 


OLS is an engineers conference and not marketing fluff at all.

> ? (something about marketing )..
> Bill- that might be worth a trip.
> Doug- this is definitely not a marketing event!
> Peter- Bill, you’re the one that needs to be there rather than me.
> Bill- I should be available at that time.
> Bill- Gunnar are you available at that time?
> Gunnar- I am open at this time.
> Matthew- We had no KDE papers submitted last year. Gunnar, you should submit
> a paper on KDE.
> Janina- we should present a paper on our proposal.  Is the meeting at HP?
> Matthew- no, its independent, at the conference center.
> Doug- Mats Wichmann is the current head of the LSB, it would be good to
> discuss the project with him.  He is with Intel.
> Janina- it would be good to have this document completed by then.  We could
> present it and see if we have agreement.  If we get agreement then we can go
> on with discussions on the test suites.
> Doug- how about at CSUN in March?
> Janina- there is a lot going on there but most of the Linux developers
> wouldn’t be there.
> Doug- when we met at Linux World, we had a suite where we could meet away
> from the floor and all the marketing.  We met a couple of extra days beyond
> the conference (away from all the marketing)

The technical groups met before the conference started, then for a
couple days during the conference in the hotel suite set up for this
purpose, away from the marketing hype.

> Janina- that’s a different kind of work.
> Doug- the group brings in a wireless connection so that everyone can
> exchange documents and we get a lot of work done.
> 
> Janina- I can get the document started and we can see how we can move it
> forward on the list.  Any other things we need to discuss?  We will have a
> meeting next week.  I hope it’s as good as the last few which have really
> moved things forwards.  See you next week.  I’ll be at the W3C conference in
> France.
> 
> Bill- did you get any good weather in Malaga?
> Janina- No, it cleared up after I left. There is a person from the EC that’s
> interested in the project.  He is from the radical party in Italy.
> Doug- Have you talked to the group from Spain?
> Janina- no, I heard that there is a group at OSCE that is doing things with
                                               ^^^^
                                               ONCE

> Linux but I haven’t met them.  Has SUN been working with them?
> Peter- not on Linux, we had a project on Java.  O’Reilly has put all its
> books on Bookshare.
> Janina- That’s great. I need to talk to Jim Fruckterman, they have a problem
> with one of the conversion utilities for Daisy.
> Peter- if a contact with Tim O’Reilly is useful, he welcomed a meeting.
> Janina- there is going to have to be a book about what we’re doing.  Talking
> at the O’Reilly conference would be a good place to talk about moving from
> the theoretical to the practical.  O’Reilly has always been supportive, we’
> ve always been able to get ASCII from them.  Well, see you next week.
> 
> 
> 
> 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

Doug
-- 
Doug Beattie
dbb at linkexplorer.com