I agree! I think it is quite likely that we will provide descriptor files since discussing this this morning. Expanding on what Steve said, I think that creating XML descriptor files should not be the second thing you do after implementing a component. Instead, it should be the *last* thing you do - i.e. they should be automatically generated from AnalysisEngineDescription.toXML as part of the build.
We had a couple of nice discussions about these issues at SETQA-NLP.
I'm still thoroughly convinced that the canonical version of an
AnalysisEngine descriptor is better represented in Java (or C++) code
than in an XML descriptor - for the sake of refactoring, type
checking, a much simpler mechanism of setting configuration
parameters, etc. However, given that the AnalysisEngineDescription
class has a number of toXML() methods, it should be straightforward to
automatically generate the appropriate XML descriptor from an
AnalysisEngineDescription object.

A nice side effect of this approach is that our users can use the
simple factory methods for creating AnalysisEngineDescription objects
with whatever configuration parameters make the most sense as defaults
for them, and generate a new XML descriptor for themselves. And
they'll get their configuration parameters appropriately type checked
before they ever have to actually load the XML descriptor.

Steve

Reply via email to