CAS / CasView API refactoring
-----------------------------
Key: UIMA-157
URL: https://issues.apache.org/jira/browse/UIMA-157
Project: UIMA
Issue Type: Improvement
Components: Core Java Framework
Reporter: Adam Lally
Assigned To: Adam Lally
Fix For: 2.1
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 a short runway 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.
Further discussion:
http://www.mail-archive.com/[email protected]/msg00945.html
Proposed sets of methods on each interface:
http://cwiki.apache.org/UIMA/casandcasviewinterfaceredesign.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
