Adam Lally wrote:
That approach is too brittle for my taste. An annotator writer would
declare a type that is meant to be a singleton, but there's no way to
enforce this. One careless annotator that creates a second instance of
such a type, and the whole analysis chain stops working. With
On 5/25/07, Thilo Goetz [EMAIL PROTECTED] wrote:
I would like to revive the discussion that started with
http://www.mail-archive.com/uima-dev@incubator.apache.org/msg01299.html
I still have the same concern about this that I posted to the previous thread:
I think Michael is onto the same
Adam Lally wrote:
On 5/25/07, Thilo Goetz [EMAIL PROTECTED] wrote:
I would like to revive the discussion that started with
http://www.mail-archive.com/uima-dev@incubator.apache.org/msg01299.html
I still have the same concern about this that I posted to the previous
thread:
I think
That approach is too brittle for my taste. An annotator writer would
declare a type that is meant to be a singleton, but there's no way to
enforce this. One careless annotator that creates a second instance of
such a type, and the whole analysis chain stops working. With my approach,
at least
Eddie Epstein wrote:
On 5/25/07, Thilo Goetz [EMAIL PROTECTED] wrote:
Technically, the proposal consists of a new built-in type and new
built-in
index as follows.
- a type uima.cas.FsVariable that inherits from uima.cas.TOP with
features
name:String, type:String and value:TOP.
The
