Thilo,
The switch from single-artifact CASes to multi-Sofa CASes and views was a fundamental change in the basic UIMA architecture. We are not doing our users a favor by hiding this change from them.
The main point of the new proposal is to make all annotator writers aware of multi-artifact capabilities, and this will be emphasized in the documentation. Maintaining the ability to run Sofa-unaware code without changes would only be bad if the resultant design suffered too much. [CAS.getIndexRepository() discussed below]
... no separate view API, just a setCurrentSofa(Sofa) on the CAS. ... setView(String viewName)
We now have experience working with a number of multi-artifact applications, and the most common practice is to be working with more than one view at the same time. Having a single CAS handle and changing which view it represents would result in a much less transparent code ["which view is the CAS pointing at now?"] as well as adding more lines of code [adding setView() calls].
I question the need for backward compatibility for Sofa-unaware annotators. Those days are over. This basic tenet robs us of the ability to clean up the CAS APIs. For example, when I look at the CAS APIs from a world where views are real, I naturally expect CAS.getIndexRepository() to return all indexes in the CAS to me, not just the ones for the default view.
So far there has been no use case for iterating over all annotations in all views. If it turns out to be important, a new method signature on CAS could be used to do so. Is this the only price we are paying for maintaining backwards compatibility?
Start discussing UIMA 3 now. Take a clean slate approach, consider how we want to handle indexing in the future. Have a couple of beta releases to get feedback from users.
Multi-Sofa code has been out and used extensively for the last 18 months. The changes in the concrete proposal are based on that experience. Eddie
