Return-Path: Delivered-To: apmail-incubator-uima-user-archive@minotaur.apache.org Received: (qmail 23660 invoked from network); 6 Jun 2009 02:07:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Jun 2009 02:07:05 -0000 Received: (qmail 79796 invoked by uid 500); 6 Jun 2009 02:07:16 -0000 Delivered-To: apmail-incubator-uima-user-archive@incubator.apache.org Received: (qmail 79727 invoked by uid 500); 6 Jun 2009 02:07:16 -0000 Mailing-List: contact uima-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: uima-user@incubator.apache.org Delivered-To: mailing list uima-user@incubator.apache.org Received: (qmail 79717 invoked by uid 99); 6 Jun 2009 02:07:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Jun 2009 02:07:16 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [128.138.128.231] (HELO ipmx1.colorado.edu) (128.138.128.231) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Jun 2009 02:07:06 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAH5qKUrAqBGb/2dsb2JhbACBT88thAoF X-IronPort-AV: E=Sophos;i="4.41,314,1241416800"; d="scan'208";a="83688069" Received: from omr-raz-2-priv.int.colorado.edu ([192.168.17.155]) by ipmx1-priv.int.colorado.edu with ESMTP; 05 Jun 2009 20:06:42 -0600 Received: from smct42-248-dhcp.resnet.colorado.edu (EHLO _128.138.42.248_) ([128.138.42.248]) by omr-raz-2-priv.int.colorado.edu (MOS 3.10.4-GA FastPath queued) with ESMTP id AXY36855 (AUTH ogren); Fri, 05 Jun 2009 20:06:42 -0600 (MDT) Message-ID: <4A29CF31.1090504@ogren.info> Date: Fri, 05 Jun 2009 20:06:41 -0600 From: Philip Ogren User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: uima-user@incubator.apache.org Subject: Re: Removing descriptor files from ClearTK References: <4A27F10E.8000107@ogren.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 > >