Adding the sendData method suggests some ideas for refactoring our AEOutput classes. First, sendData should probably just be a generic method called send on the base AEOutput interface. A bare-minimum output device just needs to implement this method and deal with known "name" identifiers describing what to do with the given "value" and, for content values, a "style" dictating presentation preferences. A later magnifier device could just implement this base class and use send for all of its purposes (e.g. sending coordinates).

Sub-interfaces such as Audio and Braille can provide default implementations of send which dispatch known, common "name" descriptors to our already existing sendString, sendFilename, sendIndex, sendTalk, sendStop, etc. methods. A device developer can easily override this base implementation to add to the dispatch switch (e.g. more if/else statements).

This change indirectly affects two other methods. First, createDefaultStyles should become optional. It is hard to think of a scenario where a magnifier device would want to come up with a different style for the default groupings of semantic tags and even layers *on its own.* Therefore, createDistinctStyles is pretty pointless. The DeviceManager will fallback on using the default style object specified by the device for everything. This is not to say that a *user* will never want to change the style per semantic or event layer. For instance, I can imagine a user indicating that items changing the background (e.g. new gaim message) should create a temporary zoomer (i.e. to show the gaim message for 5 seconds). 

Second, parseString only makes sense on devices that have the concept of string output. This method might be better placed on an intermediate interface between the base class and audio/braille.

Added to CVS. Initial testing by Scott when implementing Braille.