Yes, that's a perfectly fine way to do it! You'd update the xslt template that does the scoring and look for the features setting on the document and bump up the score there.

Another option, that wouldn't require any changes to XSLTsearch (though it would require a change to your documents and thus might not meet your needs) would be to add a property to your Document Types for mega-powerful search terms. As you know, XSLTsearch not only looks for occurances of whatever is searched for but also weights the results to show those mostly likely to be better hits at the top of the list according to the searchFields= macro parameter.

The math goes something like this to calculate the 'weight' of a page. To make it clearer, let's assume the following two pages and this XSLTsearch configuration:

XSLTsearch macro parameters include:
searchFields=pageName,@nodeName,metaKeywords,bodyText

3 Pages in the site:
@nodeName = Rock
pageName = Rock 'n' Roll
bodyText = All rock, all the time.

@nodeName = Jazz
pageName = (not set)
bodyText = All that jazz.

@nodeName = Classical
pageName = Classical
bodyText = Mostly piano and violin and stuff.

So let's imagine we searched for 'all'.

The letters 'a-l-l' are found in the bodyText of the page called 'Rock', so that page will get returned. It's total score is determined by how many times the search term is found in the various searchFields. 

The order of the searchField properties determine the weight for each match. The last item in the list of searchFields (the 'bodyText' property) will have a multiplier of 1. The next to last property (metaKeywords) a multiplier of 2. The nodeName attribute (note the @ sign indicating it is an attribute in the xml) would be multiplied by 4, and the pageName property multiplied by 8. The idea here is that when a search term is found in an earlier property or attribute it is much more significant than if found later in the list of searchFields. If the term you are looking for is in the pageName property, for instance, that is very significant, much more significant than if it happens to show up even a few times in the bodyText. The order of the searchFields is therefore very important to scoring results in a default XSLTsearch implementation. 

So, searching for 'all' gives a score of 2 for the the Rock page. That is, the search term is found twice in bodyText, and bodyText has a weight multiplier of 1 for each match. Similarly, the Jazz page gets a score of 1. Therefore, Rock is returned first and Jazz after that.

Let's imagine we searched for the letter 'a':

Rock page has a score of: 2 matches in bodyText * 1 = 2
Jazz page has a score of: 1 match in nodeName * 4, plus 3 matches in bodyText * 1 = 7
Classical page has a score of: 2 matches in pageName * 8, plus 2 matches in nodeName * 4, plus 3 matches in bodyText * 1 = 27

The results would show Classical, then Jazz, then Rock.

Now let's get clever.

If you were to add a special searchTerms property on all the docTypes and included it first in the macro's searchFields= list. Whatever term(s) are in that field will be heavily weighted in the search results. 

But wait, there's more!

A trick to give a field a MUCH higher (or lower) weight is to insert a few commas in the searchFields= macro parameter. These act as empty fields between those to be very highly weighted and those very low. Since each search field is is twice as weighty as the next in the list it adds up fast. For example, searchFields="searchTerms,,,pageName,@nodeName,metaKeywords,bodyText" would make make any hit in the searchTerms property 8X more weighty than even in the pageName property. 

Hope that explains the XSLTsearch algorithm for ranking and gives you the tools to modify it to meet your needs.

cheers,
doug.