Adam Lally wrote:
On 1/5/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Solution 1:
How about always passing in a JCasView object? For unaware components,
this would be the view to use. For view aware components, this would be
some view (perhaps picked in a similar way), but the user code would be
expected to use this or change to other views and use those.
You mean passing a JCasView to the user's process method. I'm not
seeing how that really helps, and it would create more compatibility
issues for existing code (essentially requiring JCas to be replaced by
JCasView everywhere). I don't think I like this.
I lost the train of thinking about what is passed to Annotators in the
JCas case:
is it a JCas object or a JCasView object - sounds like in your current
thinking,
it's a JCas object, right?
And for backwards compatibility, sofa-unaware annotators, we would support
constructors where the sofa would be set from the JCas "current sofa",
right?
And for sofa-aware annotators, we would have additional constructors:
- taking a an additional Sofa argument and/or
- taking a JCasView argument and/or
- both?
I think it would be good to post additional sections to the wiki
covering this, and
what is proposed to be passed to component's "process" method.
The new MyAnnotation( ....) would be changed to take JCasViews as the
object.
Yes, that's option (b) from my earlier suggestions:
"(a) add a MyAnnotation constructor that takes a Sofa as an argument,
and/or (b) add a MyAnnotation constructor that takes a JCasView
instead of a JCas."
The featureStructure.addToIndexes() could work if the Java cover object
cas/jcas ref object pointed to the view. For JCas cover objects, we
could
keep this pointing to separate instances of the JCas _Type objects, but
that might
get a bit expensive - we'd need to have separate instanced of the _Type
objects
for each view (but that's how it's working today). For giant type
systems, (1000 types),
that's a lot of stuff to create - but maybe there's a "lazy" way to
delay creation and
only create those that are actually "used". This would involve I think
modifying the
generator code to allow the generator to be absent, and created on first
need.
This seems like a lot of trouble to go through to support
addToIndexes(). It seems better if we can get our users to switch to
calling JCasView.addFsToIndexes(fs) instead. So I think I'd still
like to see addToIndexes() be deprecated and only work for the current
view.
I think I agree with this thought, though I bet our users don't like it
for the
single sofa case. If we can make that case work, I'm OK with requiring
sofa-aware components to say which view they want to index things in when
calling add/removeTo/FromIndexes.
---------------
Solution 2:
General problem:
new Annotation and add/removeTo/FromIndexes need additional argument:
- the Sofa for Annotation and
- the index-set (or view) for the add/removeTo/FromIndexes
sofa/view-unaware components want to ignore this issue (for simplicity).
How about a new framework method that lets
users set the current view/sofa? This follows the use case that normal
view-aware code works with one view at a time, in terms of
adding/removing
information. It has a bad aspect of being a bit indirect, and
side-effect-ish.
So I don't think I like it as much. But here's what it might look like:
<snip/>
That's a lot like what we have today, where users interact with the
JCas interface in order to interact with views. You've essentially
just replaced getView() with a method like switchView(), that changes
what view the JCas is pointing at. That seems problematic becuase it
would also change the view for any other piece of code that might have
had a handle to that JCas. I take it that's what you meant by
side-effect-ish.
Here's a specific proposal:
1) deprecate TOP.addToIndexes(). Document that it's here only to
provide compatibility with older single-sofa code, and does not
support multi-sofa code. Suggest that users migrate to
JCasView.addFsToIndexes(fs) instead.
(or fs.addToIndexes(JCasView) ? <Note: this is currently an existing API,
if you change JCasView to JCas, since right now we don't have a separate
JCasView> )
I agree with this for sofa-aware components. For sofa-unaware components,
it seems like extra work to require specifying the view.
2) Add the constructors AnnotationBase(JCas, Sofa) and
AnnotationBase(JCasView). These set the sofa pointer of the new
annotation appropriately.
Yes, these seem appropriate.
3) Deprecate the constructor AnnotationBase(JCas). It always sets the
Sofa reference to the "current view" and does not support multi-sofa
code. Users should migrate to one of the other constructors.
I'm not sure we want sofa-unaware components to write as if they were
aware of all the multi-view, multi-sofa machinery. If a large percentage
(more than 50%) of the components are sofa-unaware, and most people
climbing the learning curve on UIMA start here, it seems a good thing to
make this path simple. If we could - I would say to deprecate this for
sofa-aware components, but not for sofa-unaware ones :-)
4) Apply the above changes to all subclasses of AnnotationBase, and
update JCasGen to generate the appropriate constructors for subclasses
of AnnotationBase.
5) Either we enhance our migration utility so that it makes these
constructor changes automatically, or we require users to rerun
JCasGen when the migrate to Apache. The latter is starting to not
sound like such a bad thing. In any case, custom constructors that a
user added would need to be manually addressed by the user.
-Marshall
