I think there is no problem at all after I noticed that the analysis engine can use its local names of the views. I cannot use an arbitrary input view, but the initialView. It's not what I preferred, but it solves my problem.
Sorry about the inconveniences. Best, Peter Am 22.04.2014 12:47, schrieb Peter Klügl: > Am 18.04.2014 15:23, schrieb Eddie Epstein: >> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl <[email protected]>wrote: >> >>> Am 17.04.2014 15:01, schrieb Eddie Epstein: >>>> Hi Peter, >>>> >>>> The logic is that since a sofa aware component may have one or >>>> more input and/or output views, such a component needs to use >>>> getView to specify which to use. >>>> >>>> For sofa aware delegates, sofa mapping enables the delegate to >>>> hard wire input and/or output View names in annotator code (or >>>> annotator config parameters) and then have the real View names >>>> assigned via mapping in the aggregate. >>> Is the real view name in the mapping important at all since the view get >>> accessed by the implementation in the process() method? >>> >> The real view name is what will be used when the CAS is serialized >> to a file or to a remote service. >> > > Yes, but that has nothing to do with the mapping, which is still obsolete. > > >>> I don't see the effect of the mapping to the default input view of an >>> sofa aware AE without input view capabilities at all. The mapping says >>> view1 is linked, but another one arrives. >>> >> The input view for a sofa aware component is always the base CAS view, >> for the reason given above. >> > I don't see the reasons. Why shouldn't the analysis engine get the view > mapped in the aggregate? If the analysis engine has more input views, > then it gets the base view and still can access them in the > implementation. It actually has to anyway right now. If it has only one > (or only the default view), then it can directly use the given one > without a static implementation (getView("name")) or an additional > parameter. I think this would enable the creation of better components > and I actually have a use case right now. > > >>> So, the best practice is to introduce a parameter for specifying the >>> input view? In case that the AE implementation should be used several >>> times in an AAE for different views. >>> >> Many if not most view aware components I've seen do not have a single >> input view. > > Ruta has some, which do not work in pipelines when cascaded. > > Maybe I missed something, but I do not yet see any reasons why it should > get the base view. > > Peter > > >> Eddie >>
