On 1/2/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
I think this proposal also has one set of index "definitions", and each view
gets its own private set of index-instances for these definitions.
Correct.
Will the methods not really associated with a CAS object (they are or
could be
static methods) still be on the CAS or CommonCas:
createFilteredIterator, getConstraintFactory, createFeaturePath,
createFeatureValuePath, and fs2listIterator
I'm not sure they can be static, as they may depend on the type
system. Some of them, anyway. I think these should still be on
(Common)CAS, but might also be on CasView for convenience. This is
seeming like a slippery slope, though, pretty soon everything is in
two places.
I suggest that the methods that belong in the CasView be left there
(deprecated)
to operate on the "current view":
get/set for Sofa things like DocumentText, SofaDataURI, etc.,
getSofa
getIndexRepository
getAnnotationIndex(type)
get/set associated with DocumentAnnotation (I think there one of
these per "view" - agree?)
add/removeFsTo/FromIndexes
Agree.
For things like createView and getView(String or FS) - I'm ok with
requiring these to be on the CAS Api only, but
also wouldn't object if they were on the CasView API for convenience.
I prefer leaving them off the CasView.
The CAS has a getLowLevelCAS() method; the low level CAS includes both
things for FSs and also for IndexRepositories.
The index repository things should be looked at carefully to see if they
should go with the "view" (with perhaps "convenience" functions working
on the current view in the CAS Api).
Good point... we may need a LowLevelCasView. (Currently the situation
with LowLevelCas is the same as with CAS - an instance of LowLevelCas
could either be referring to a view or to the "base" CAS.)
And don't forget JCas, where we'll need a JCasView.
When I get a minute I may try to compile a complete list of proposed
changes, maybe on the Wiki.
Finally :-) we have getSofaIterator... on the CAS Api (I'm not
distinguishing between CAS and CommonCas APIs here).
I suggest for 2.1 we "lock" the association between 1 view <==> 1 sofa.
So we won't need getViewIterator, nor have to
figure out how to "name" views separately from Sofas. Is that too
restrictive?
I agree, Sofas and Views are still 1-1 for the time being. And
getSofaIterator would only be on CAS, not CasView.
-Adam
