On 12/14/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Sure, those would be on the view as well. Would we then have
text-specific views, like TCasView? I'm not proposing this, mind you,
just asking.
My sense is we want to stay away from modality-specific views.
Perhaps I might change my mind if there were a compelling argument. I
think we'll need to have a JCasView, though.
CasView viewOfMySofa = inCas.getView() ?
+1 to that.
I'm OK with this being the way that new code does things, but still
think it's important to have a deprecation strategy for older code.
inCas.getDocumentText() would not work, +1 to that. However, I was
thinking that you would be able to access *all* indexes (and their
contents of course) from the CAS, not just the sofa-neutral ones.
Perhaps you wouldn't know how to interpret the sofa information, but the
annotations would still be accessible. I think this is consistent with
your idea/proposal that the CAS is the container of all data. Was this
also what you were thinking?
Let me see if I can summarize where we are now:
* Index definitions are shared across the entire CAS.
* Each defined index will have one instance in the CAS as well as an
instance for each view (or sofa? right now sofas and views are 1-1 so
it doesn't matter but I wonder what the right terminology is)
* You can add FS to the indexes in a view (or multiple views). You
can also add FS to the indexes on the CAS, which is a place to store
indexed FS that don't belong to any view.
* If you get an iterator over an index from the CAS, this iterator
will return you FS that were indexed in the CAS well as FS that were
indexed in any view.
-Adam
