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
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.
- Removing descriptor files from ClearTK Philip Ogren
- Re: Removing descriptor files from ClearTK Steven Bethard
- Re: Removing descriptor files from ClearTK Philip Ogren
