Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of sokolov@ifactory.com
 designates 68.236.111.2 as permitted sender)
Message-ID: <4DBDEE19.5090305@ifactory.com>
Date: Sun, 01 May 2011 19:34:49 -0400
From: Michael Sokolov <sokolov@ifactory.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: dev@lucene.apache.org
Subject: Re: Re: Solr Config XML DTD's
References: <BANLkTimaSNh1rU7Gw3_qvu1UE1AYwtqQfw@mail.gmail.com>
In-Reply-To: <BANLkTimaSNh1rU7Gw3_qvu1UE1AYwtqQfw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

My first post too - but if I can offer a suggestion - there are more 
modern XML validation technologies available than DTD.  I would heartily 
recommend RelaxNG/Compact notation (see 
http://relaxng.org/compact-tutorial-20030326.html) - you can generate 
Relax from a DTD, but it is more expressive, while still being easy on 
the eyes (uses curly-brace syntax), and much simpler than XML schema.

In particular it lets you express wildcard constraints like:

start = anyElement
anyElement =
   element * {
     (attribute * { text }
      | text
      | anyElement)*
   }

which matches absolutely anything.

I'm not sure what kinds of constraints can actually be applied to solr's configuration in practice?

But using a formal constraint language will give decent error reporting out of the box.

Java-based tools for Relax validation and conversion are available here: http://code.google.com/p/jing-trang/

-Mike S

On 2:59 PM, Michael McCandless wrote:

> If not a DTD, can we put some more "customized" form of validation for
> Solr's configuration?
>
> In general, I think servers should be anal on startup, refusing to
> start if there's anything off in their configuration.
>
> (Of course, along with this, the error messaging has to be *excellent*
> so you know precisely where the problem is, what's wrong, how to fix
> it).
>
> If you take the lenient/forgiving approach then you wind up with Solr
> instances in unknown states -- the app developer thinks they turned X
> on, everything starts fine, but then, silently, inexplicably, it's not
> working.  This then leads to frustration, thinking Solr is buggy, not
> using this feature, blogging about problems, etc.
>
> Mike
>
> http://blog.mikemccandless.com
>
> On Tue, Mar 29, 2011 at 7:15 PM, Chris Hostetter
> <hossman_lucene@fucit.org>  wrote:
>> : Hi, this is my first post to the mailing list.  I'm working on a commercial
>>
>> Welcome!
>>
>> : My DTD works for our internal version of queryElevation.xml, but since the
>> : ATTRIB name of the<doc/>  tag could be anything, I'm not sure how to write a
>> : DTD that would validate any valid query elevation file.
>>
>> right .. this is one of the reasons why we've never tried to publish a DTD
>> for the solrconfig.xml or schema.xml files either.  there are lots of
>> cases where plugins can define arbitrary attributes on the XML nodes.
>>
>> If i had the chance to do it all over again, and i better understood xml
>> back when yonik first showed me what the configs would look like, i would
>> have suggested using xml namespaces .. but that ship kind of sailed a
>> while ago.
>>
>> we're getting a little better -- moving towards using the same type of
>> "NamedList" backed XML for the initialization anytime new plugins are
>> added, but i don't see it being feasible to have a config DTD anytime
>> soon.
>>
>> -Hoss
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org