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);

Reply via email to