As I see it, we're not going to reach consensus on this issue. I guess
this is at least in part due to the fact that we disagree on the basic
premises underlying this redesign. I am -1 to the current proposal, and
I'll give my reasons below. However, I think we've mostly discussed
most of what I have to say, and if everybody else thinks the current
proposal is a good idea, I will not stand in its way. Anyway, here goes.
The current view redesign proposal IM not so HO doesn't help in making
views any clearer. We are perpetuating the current view implementation,
albeit with a handful of additional interfaces that are 90% identical to
the CAS interface. That shows that there's something seriously wrong
with this design. If this is all we want to do, there's a much simpler
way: no separate view API, just a setCurrentSofa(Sofa) on the CAS. With
a default Sofa, that gives us 100% backward compatibility. I'm not
seriously proposing this, mind you, but it's preferable to the current
proposal (but see below).
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. By sacrificing a
clean design to backward compatibility, we may keep some existing users
happy, but we're not going to gain any new ones. If even UIMA
developers find it that hard to get their heads wrapped around the
concepts and APIs, how much harder is it going to be for new users?
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.
The CommonCas interface adds to the confusion, because it isn't (a
common CAS API). It follows the methodology that everything that can be
abstracted, is abstracted. However, that's not how people think. We
like to think in API groups and what things logically belong together,
not what can and can not be grouped because of method return types. So
all it does is add to the confusion because you always have to look in
two places for APIs.
So here's what I would do:
- No view API in UIMA 2.x. Possibly change the view/sofa related APIs
in a manner indicated above (CAS getView(String viewName) -> void
setView(String viewName) etc). I would find that much more intuitive,
but I'm not hopeful that other people on this list will.
- 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.
- Support both UIMA 2 and 3 in parallel, for as long as necessary.
Consider interoperability, possibly in the same JVM.
I really think that the CAS/view redesign proposal as it currently
stands will make things even worse, and that it should be reconsidered.
--Thilo
