On 12/11/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
So what about Adam's suggestion to separate a CAS from a view? What *is* the difference, conceptually?
A View has an index repository and a Sofa. (The Sofa may become optional, but in the current impl. it is not.) A CAS holds the analysis metadata (i.e., it has the heap) and contains one or more views. It does not itself have a Sofa or an index repository. So basically, if we split the interfaces then CAS interface would lose the Sofa-access methods and the getIndexRepository() methods. The CasView interface would not have getView() methods, but otherwise would look pretty much like the CAS interface does today.
If we did separate the interfaces, could we provide a process method that gets the default view as input?
This is basically where we were when we were using the TCAS interface as the equivalent of a CasView interface, but this ran into lots of problems. We had different annotator interfaces, some of which took TCAS as an argument and some of which took CAS as an argument. Yet others took JCas as an argument, and it was not clear whether the JCas was an interface to the whole CAS or just a view (i.e., did it wrap a CAS or wrap a TCAS). Then there were the CollectionReader and CasConsumer interfaces, which always took only CAS as an argument. Basically, there are too many different variants of the process call in this scenario. It was simpler to have only a single set of annotator interfaces that vary based on the type of CAS implementation they take -- CAS, JCas, or whatever we think of next. This is where our current implementation stands. The unfortunate confusion that remains is that for an annotator with e.g. a process(CAS) signature, that CAS could be either the base CAS ("whole CAS"?) or a view. This is determined by the annotator's descriptor. I do like that Eddie's suggestion makes things more uniform. process(CAS) always gets the base CAS. But I think it is still very confusing that getView() returns an object of type CAS. I can see the user conceptualization now: void process(CAS casObjectThatDoesntWork) { //why does this method throw an exception? //casObjectThatDoesntWork.getDocumentText(); CAS theCasICanActuallyUse = casObjectThatDoesntWork.someMethodIDontUnderstand(); //ok now it works? theCasICanActuallyUse.getDocumentText(); } :/ -Adam