Well, the concrete may not have quite set yet... but here goes:
1. Goals The following are confusing (or some might say, "broken") (a) the interface "CAS" can be an interface to either the whole CAS or to a view. Methods like this are poor: CAS view = cas.getView(name); (b) the logic determining which "CAS" (a view or the whole CAS) gets passed to an annotator's process method is needlessly complicated. We would like to improve this in v2.1, so we have 3 weeks (starting now) to implement it. It's acceptable if what we do breaks multi-view annotators/applicatoins, but it cannot break single-view annotators/applications. We want whatever we do to be easier to document and explain to users than what we currently have. 2. Proposed Solution We don't plan to change the fundamental design of views at this point - there isn't time and it's too controversial. A view still consists of an index repository and a Sofa. (Yes, I know someday a view may not have a Sofa - but for now, it does.) A. New CasView interface We create a new interface CasView. All of the CAS.getView() methods will now return type CasView (instead of CAS). The CasView interface will contain all of the sofa-access methods and indexing-related methods that are on the CAS interface. A more controversial question is whether you can create FS from a CasView - i.e., does the method CasView.createFS(Type) exist? What about CasView.createAnnotation(Type, int begin, int end)? In some previous discussions we said no, FS creation is on the CAS only. This communicates to the user that, logically, FS creation is an operation on the CAS as a whole. However after thinking about this more I think that may be too inconvenient. If I have a handle to a view and want to create an FS I'd have to do: myView.getCAS().createFS(type); which is a little tedious. (and this assumes we have CasView.getCAS(), without which it is much worse). And what about annotations, which need a Sofa reference, so we would need something like: myView.getCAS().createAnnotation(type, myView.getSofa, begin, end) which is too ugly to consider. All in all I think it would be better to allow FS creation of the CasView interface as well as the CAS interface. I think we can explain this. A view is a "window" into a CAS - a particular way of looking at it - it should be a fully functional interface for interacting with the CAS from that viewpoint. And that would include creating new FS. B. Backwards Compatibility To meet the goal of being compatible with single-view annotators, we will use the following strategy: The idea is that a CAS has a "current view". Any methods on the CAS that are view-oriented will apply to the current view. This includes but is not limited to: getSofa() getDocumentText() getIndexRepository() addFsToIndexes() createAnnotation(int begin, int end) //needs to know which Sofa to refer to The current view is determined by the framework and can be different for different annotators. For single-sofa annotators the current view is the view that the annotator should process, as determined by sofa mappings in the usual way. Note that this approach also allows single-sofa application code to work. We have a lot of code that does: AnalysisEngine ae = ... CAS cas = ae.newCAS(); cas.setDocumentText(someString); ae.process(cas); and it would be really nice if this continues to work. We could deprecate these APIs and encourage people to switch to the view-oriented APIs, which would be something like: AnalysisEngine ae = ... CAS cas = ae.newCAS(); CasView initialView = cas.getInitialView(); initialView.setDocumentText(someString); ae.process(cas);