The biggest conceptual difficulty as it now stands with me is that an AnnotationIterator over Abbreviations, has anything to do with the relative priority of Entities. I think I had it conceptualized that a subiterator with a type is an iterator over its own container constructed in the simplest way possible: take all the annotations of a given type with begin offsets greater than x and end offsets less than y and through them in. It isn't the type priorities themselves that felt like they were an implementation convenience but the unexpected behavior. Using the naïve algorithm is inefficient compared to the actual implementation because it doesn't have to iterate through the all the annotations but the way the implemented algorithm's behavior diverges from the naïve algorithm wouldn't be easily seen without its documentation in the api (which I missed).
-----Original Message----- From: Katrin Tomanek [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 12:05 PM To: [email protected] Subject: Re: Type Priorities Hi, > I don't like the behavior, either. However, type priorities were > introduced because of user requirements. They're certainly not > an implementation convenience. Quite the opposite, in fact :-) > > Now if enough users speak up, maybe we can change something. > Perhaps by default, type priorities should not be used and > you'd need to do something special to activate them. One > might imagine special iterator overloads that respect type > priorities. yes, I think thats very a good idea. > The problem that type priorities are trying to address is > a valid one, IMHO. I'm just not sure that the way we're > tackling this is the best one. IMHO its a little bit unintuitive that by default the subiterator uses the priorities in this way: I would just not have expected that when two types have the same spans and one has inferior priority, the subiterator would not return me this type. Katrin
