Thilo Goetz wrote:
<snip> I think the difficult UIMA developers find is not necessarily
an indication of the difficulty users would have. UIMA developers
are trying to keep multiple use cases of multiple kinds of users
(e.g. sofa-aware, sofa-unaware) in mind simultaneously, and come up
with a design which satisifies all of these somewhat conflicting
goals, simultaneously. (That's why we're having all these headaches
:-) )
I don't think so. I've helped many a new user through their initial
and growing UIMA pains (and so have you, I know). There's certainly a
lot of confusion with the CAS/JCas interfaces we already have, and the
current proposal doesn't make things easier (it eliminates virtually
no APIs, but makes some deprecated and adds a whole bunch of new ones,
without adding any functionality).
Perhaps a useful thing to explore is to consider merging *all* the
"user-facing" CAS APIs (CAS, CASView, JCas, JCasView), thereby
*eliminating* some APIs. I'm thinking we would still have the ability
to have multiple views, each having a different "object" implementing
the API; but there would be just one Interface API for this. In other
words, the CAS getView(...) method would return a CAS.
Also I'm thinking we would still support JCas and CAS, while getting rid
of the JCas Interface. For instance, the "new MyAnnotation(....)"
methods could take a CAS argument - it's trivial to get the
corresponding JCas from a CAS Object.
What does this "break" in the bigger picture?
- It diminishes somewhat the multi-view notion, because there's only
one API, not a separate one for the "View".
What does this "enhance"?
- Users learn only one interface, don't get confused about having
multiple ones. I think users have "asked" for this kind of
simplification before.
There's probably something fundamentally wrong with this, so let's here
what it is; I'll try not to get too embarrassed :-)
-Marshall
