As a follow-up of our SAGA sessions at OGF 19, here is one way on how to proceed with the SAGA Java Bindings and in fact with some other language bindings as well. Now this is to open the discussion and I don't want to impose the concept. So all of you that have interest in the Java binding please let your voice be heard. We have seen that each implementation of SAGA going on is not necessary standardized and not complete. The SAGA specification stipulates that partial is possible and each language bindings can introduce its specific flavor. That isn't the best way to get a standard around the corner. Java is a powerful language that allows a high level of abstraction. SAGA should follow a path similar to what has been done with, for example, XML: org.w3c.dom, org.xml.sax and JAXP. That means that SAGA: - Must have a complete abstract API based on façade Interfaces, - Minimize the number of concrete classes to Exceptions, Error and Factories (or Service Provider Interfaces - SPI), - Allow multiple vendor implementations in the back. For example multiple XML parsers can be installed at the same time. - Have a mechanisms to use one or more implementation at the same time, the user can choose one explicitly or not, - If one implementation does not support a specific section of the specification, a safe fall back mechanism should allow another implementation to be used transparently. The general SAGA API should have a common namespace like: org.ogf.saga. Specific implementation can be anything like nl.vu.saga. If the SAGA API façade is available and stabilized it could/should be submitted to the Java Community Process to become an official Java specification for Grid applications through the JSR (Java Specification Request). Pascal Kleijer k-pasukaru@ap.jp.nec.com