On 1/8/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
By all means, though I would like to understand what the issue is we're
addressing here.  Is the concept so difficult/outlandish?  Is the
documentation so bad?  Are the users so slow?  What is it that makes
this so difficult?


It's probably a combination of things.  I think the concept is unusual
enough to not be obvious.  It's documented, but finding that page of
the manual isn't that easy.  It's not covered in our tutorial
examples.  Users aren't slow (shhh... some might be listening!) but
are busy and will take the shortcut (extending annotation) rather than
search the manual.  In any case even if documented well I still think
it's too much work to create a bag index, if the framework can just do
that by default.


If I understand your proposal correctly, it does not address singletons.
  I had once suggested to allow named instances of FSs (you might call
them global variables), declared in the descriptor.  Is this something
you want to address as well, or are you happy with just the
user-friendly bag indexes?


Right, this doesn't address singletons per se, although I think it
helps.  It still may be a little annoying to have to use an iterator
when you know there's only one instance.  We might improve this by
adding a method IndexRepository.getInstance(Type) that returns the 1
object of that Type if there is only one, and throws an exception if
there are 0 or 2+ instances.

I'm not sure about the global variables - it might be OK but it's
another set of names that have to be agreed upon between cooperating
annotators.  Do annotators declare in their capabilities that they
require certain variables to be set or that they change the value of
certain variables?  I'm just not sure it's worth it to introduce this
concept.

-Adam

Reply via email to