
To be resolved.
---------------

* From Paul Lamere <paul.lamere@sun.com>

  The GSAPI interface provides a nice and simple method for determining 
  which markup language to use. I have no quibble with that.   The tough 
  part for an application writer is having to deal with all markup 
  possibilities.  For instance, if I want to write an email reader for 
  GSAPI that makes use of the synthesis markup language to emphasize the 
  subject and the sender, and speak the body of the text faster than the 
  subject, I'd have to write an output driver for JSML and SSML so that if 
  I am running somewhere that only supports one  markup, my application 
  will still work.  

  Its like in the olden days when an application writer had to support 
  different printer languages (postscript, HPLJ, epson, and tty), so that 
  the application could print in the likely environments.

  A statement in GSAPI that says, 'a synthesis engine *must* support SSML' 
  would take care of this problem from an application writer point of 
  view, the application author would then need to just write to the SSML 
  spec. and would not have to worry about others. However, this may make 
  it much more difficult for  TTS vendors to support GSAPI.  If their 
  engine doesn't support SSML they may just not bother to support GSAPI at 
  all.

=============================================================================

Documentation.
--------------

* Consider putting back in the equivalent of the Java code in the comments,
  that I took out.

* Might need to adjust the JavaDoc styling for all occurances of "null".

* When the script to generate the JavaDoc documentation is complete, we will
  need to go back and fixup any links it couldn't match/cross-reference.

* Need to fixup occurances of java.lang.System properties in the comments.

* May need to fixup comments for any Java specific exceptions.

=============================================================================

Things to consider.
-------------------

* In doing the IDL conversion, most (all?) of the method arguments that are 
  not basic types hava direction of "in". Need to test if using "in" to 
  define the direction for parameters on methods gives us the ability to do 
  what we need to do within GSAPI. Otherwise we are going to need to use 
  "inout".

=============================================================================
