Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <4268A980.3050807@culture.gouv.fr>
References: 
 <042220050249.13376.426866200006966E000034402200762194900A0B020E089B0A@comcast.net>
 <4268A980.3050807@culture.gouv.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <a10973f7b57d914abc5823ed2866a37f@activemath.org>
Content-Transfer-Encoding: quoted-printable
From: Paul Libbrecht <paul@activemath.org>
Subject: Re: token type question
Date: Fri, 22 Apr 2005 12:19:13 +0200
To: java-user@lucene.apache.org


Le 22 avr. 05, =E0 09:36, Pierrick Brihaye a =E9crit :

>> Are you say that I should construct Token in analyzer like
>> new Token ("chem_H2O", 100, 103, "chem");
>> note that chem_ is added prefix to H2O, and 100 to 103 is length of=20=

>> H2O rather than chem_H2O?
> Well... 100 to 103 are offsets provided by the reader (an are thus=20
> usually offsets in the source file). These offsets may help you to=20
> make some computations but they are lost when the token is indexed.

?? not in all situations, or ?? You couldn't render it back otherwise=20
as is done search-result highlighting.

One thing that tackles me is how much this parameter could, again, be=20
something different...

In particular, I'd much prefer to have it a tree-path instead of a=20
plain number. I don't have reader plain numbers and they are, often,=20
lost in an XML content-base.

hopeable ?


thanks

paul=


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