On Tue, Feb 24, 2009 at 2:53 AM, Thilo Goetz <twgo...@gmx.de> wrote: > I have found the discussion again that I was referring to. It wasn't > on this list, it was in the OASIS spec discussions. Sorry about the > confusion. I don't feel at liberty to publish that conversation here, > but maybe Adam would like to comment? He and I were debating this at > the time (nearly two years ago). >
I'm not sure about what OASIS discussion you mean (is it about xmi:id consistency?), but I thought the link that Marshall posted was a reasonable summary of the discussion, including the concerns that I had: http://markmail.org/thread/aolbz4nrvmgjhuyb. The only sticking point I was really concerned about was the invalidation of the FS handle held by an application. But, it was definitely not my intention to shoot down any work in this area (in fact you'll see in that email thread where I explicitly said I'm in favor of doing something in this space). I just want to discuss it and see if we can come to a mutually acceptable plan. To address Eddie's point about Vinci services breaking FS handles already - I consider that a bug, so am not happy using that as a rationale to invalidate FS handles as a general policy. And I'm worried that users who haven't been using Vinci services (I bet we have plenty of those) have built applications that rely on this behavior. I remember suggesting that we post on the user list about this, but am not sure if we ever did. If you do a GC approach, is there not any way to include application-created FeatureStructures as part of the "root" set? Or to look at it another way, the set of FS's that you do the GC over is only those created since the CAS was input to the current AE (possible aggregate). It seems like Marshall's angle (if I understood it) is not really GC at all, but a model where an annotator decides to explicitly delete FS. I could be okay with that idea, too. A GC model by definition should preserve any referenced FSs, but if we say we have an explicit deletion model where anybody can delete anyone else's stuff, at least we won't confuse people about what's going on. Current applications that use existing annotators would not break (because the annotators would not delete anything), and if a new annotator is introduced that breaks the application, it's the annotator's fault for being too aggressive in deleting stuff that someone else might still need. -Adam