#13 ldi parameter parser to be smarter or more strict

[gennff]

hi,
the ldi parameter parser needs some rework to better support problem recognition with wrong or non-exact indexing configurations. The following "typo" trapped me today and i expect the parser to either warn me about the typo and reject further processing or to be smart enough to correct the typo silently. Here is an example (from docu 3.1.4 / email-table and sorting):

1.
leaving a whitespace for FormatCols like this "FormatCols:subject(NOT_ANALYZED), emailFrom(NOT_ANALYZED)" stops applying the NOT_ANALYZED option just after the whitespace as the trace output proves:
FINE: Document<stored,indexed<rowid:AAAWvbAAGAAABrrAAA> indexed,tokenized<BODYTEXT:BODYTEXT> indexed<emailDate:20110617> indexed<subject:SUBJECT> indexed,tokenized<emailFrom:EMAILFROM> indexed,tokenized<emailTo:EMAILTO>>

2.
removing any whitespaces from the FormatCols section delivers the expected result:
FINE: Document<stored,indexed<rowid:AAAWvbAAGAAABrrAAA> indexed,tokenized<BODYTEXT:BODYTEXT> indexed<emailDate:20110617> indexed<subject:SUBJECT> indexed<emailFrom:EMAILFROM> indexed<emailTo:EMAILTO>>

Concerning the parameter string i would also vote to allow for line breaks between sections of parameters to have a more comprehensable layout of the sql statements.

p