Nomination for TC Secretary; fulltext search syntax

[<david.choy@emc.com>]

To all,

As Al and Ethan both are leaving the TC, we shall conduct an election
for a new TC Secretary.
The TC Secretary takes attendance and prepares minutes for TC meeting.
In addition, he/she is empowered to help out on some administrative
matters. For the next two weeks, until the 23 August TC meeting, please
send nomination for TC Secretary to me and cc the nominee. If you are
interested in the position yourself, please feel free to nominate
yourself. We plan to compile a list of nominees by the next meeting, and
set up a ballot afterwards.

We discussed today the proposal to adopt a subset of the Lucene syntax
for fulltext search (#660) -- the subset that functionally corresponds
to what is provided by v1.0. Currently, the opinions within the TC
seemed to split between "we should adopt an existing standard" and "we
should avoid backward incompatibility". By comparing the two syntax, I
think we are talking about the following three specific changes if the
Lucene syntax is adopted:
(1)	Change single-quotes (v1.0) to double-quotes (Lucene) for
phrase. This was the original #660 proposal.
(2)	Fulltext terms not separated by a Boolean operator are OR'ed
(Lucene) instead of AND'ed (v1.0)
(3)	Negation is not allowed for a single-term expression (Lucene).
V1.0 does not have this restriction. So, v1.0 is actually more demanding
on a server than a Lucene subset is (e.g. find documents that do not
contain "CMIS").
I suggest that we assess the proposal in light of these three changes.
If you feel strongly one way or another, please add your
thoughts/opinion to #660.
One other difference between 1.0 and Lucene is character escape. But I
believe, so long as we imbed fulltext expression in a SQL statement, we
will have our own escape rules no matter what. (If there are other
differences that I missed, please let us know.)

We also have a retention proposal posted two weeks ago. If you are
interested in a retention capability, please inject your thoughts.

Regards,

david