It's a simple point. Let's say you are not a programmer, but rather, an "assembler" of annotators. Let's imagine that you can't read Java (assuming annotators written in Java) or C++ (assuming annotators written in C++), but you can read XML.
Then you can see by looking at the XML what the parameters are; while, if they are kept inside the "code", only people who can read the code can see this. The other reason for having externalized things in XML, is to enable tooling that can be "driven" from this. For example, the Component Descriptor Editor has various features that work from the XML specifications of configuration parameters. It's quite simple to add a bunch of overrides by just clicking in an aggregate - the CDE is using the XML to figure out the details. Configuration parameters can also be quite complex, grouped into various "sets" (I don't recall the details right now, but it's something like being able to select different parameter settings in a group depending on things like the document language -- see http://uima.apache.org/d/uimaj-2.3.1/references.html#ugr.ref.xml.component_descriptor.aes.configuration_parameter_declaration), and the Component Descriptor Editor goes to some lengths to make this complexity appropriately usable. There's an old Jira that says the configuration parameter groups architecture in UIMA is too complex, ( https://issues.apache.org/jira/browse/UIMA-114 ) but I've occasionally heard from users that are using them, so I don't think we're likely to drop support for them (unless some much better design comes along to make it worthwhile giving up backwards compatibility :-) ). -Marshall On 10/18/2011 5:55 PM, Jörn Kottmann wrote: > On 10/18/11 10:41 PM, Marshall Schor wrote: >> One thing that UIMA is "about" is the creating of compose-able components, >> and >> supporting different skill sets / roles for users of the framework. Re: this >> last point, we have a role called "assembler" in mind, someone who may not >> know >> any details of programming languages (annotators might be developed in Java, >> or >> C++, or ...), but can do some xml editing (perhaps with a form-based editor), >> and put together and configure a pipeline of annotators, developed by others. >> >> This kind of use case leads to the posture where we have externalized >> configuration parameters and settings, in XML, outside of the annotator >> implementation. > > Maybe I missed the point, but is there any reason that the configuration > parameters > need to be externalized? I can see that people want to change settings, but > for that > the "configuration parameter settings" should be enough. > > Jörn >
