[Solr Wiki] Trivial Update of "MakeSolrMoreSelfService" by KenGeis

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "MakeSolrMoreSelfService" page has been changed by KenGeis:
http://wiki.apache.org/solr/MakeSolrMoreSelfService?action=diff&rev1=5&rev2=6

Comment:
fix spelling

  This is a collection of ideas about ways to make individual
  installations of Solr more "Self Service" for clients.
  
- (A lot of these ideas come out of an informal discussion that happened at CNET a little while before Solr was open sourced.  We were talking about things that oculd be done so that all you needed to "discover" an installation of Solr - and what could be done with it - was a link to the /admin screen.  From there you could get all the info you needed without wondering where it might be documented externally.)
+ (A lot of these ideas come out of an informal discussion that happened at CNET a little while before Solr was open sourced.  We were talking about things that could be done so that all you needed to "discover" an installation of Solr - and what could be done with it - was a link to the /admin screen.  From there you could get all the info you needed without wondering where it might be documented externally.)
  
  = Misc =
  
@@ -26, +26 @@

     <indexDescription>
       <p>
       This index contains product data from the
-      <b>personal electroncs database</b>.
+      <b>personal electronics database</b>.
       It is built using the PEDBuilder, and updated hourly by the PEDUpdater.
       </p>
       <p>
@@ -66, +66 @@

      
  == Request Handler Param Docs ==
  
- In addition to the `<init>` options that Query Handlers can use anyway they want, there should be a machanism when registering handlers to specify what query params it supports, with descriptions, and some basic info on how they should be displayed in a form.
+ In addition to the `<init>` options that Query Handlers can use anyway they want, there should be a mechanism when registering handlers to specify what query params it supports, with descriptions, and some basic info on how they should be displayed in a form.
  
  Perhaps something like...
  
@@ -104, +104 @@

    </requestHandler>
  }}}
  
- At first glance, it may seem like this info should be returned by some method in the !SolrRequestHandler interface, but i think it makes more sense if the person registering the handler gets to specify what options are "publicly" advertized for the specific instance of the handler.
+ At first glance, it may seem like this info should be returned by some method in the !SolrRequestHandler interface, but i think it makes more sense if the person registering the handler gets to specify what options are "publicly" advertised for the specific instance of the handler.
  
  
  = Advanced Search Form =
@@ -124, +124 @@

  = Schema Explorer =
  
  Having a link to the `schema.xml` file from the `/admin` screen is useful, but 
- given the way fields can inherit/override options form their fieldtype, it's not allways easy to understand what you are looking at.
+ given the way fields can inherit/override options form their fieldtype, it's not always easy to understand what you are looking at.
  
  A Schema Explorer page should exist, with features like...
  
@@ -135, +135 @@

      * termVectors
      * multiValued
      * omitNorms
-   * list of all field type backing classes (ie !SortableIntField, !DateField, !TextField, etc...) found in a fieldtype.  For each class provide a list of all fieldtypes "with details" using that class.
+   * list of all field type backing classes (i.e. !SortableIntField, !DateField, !TextField, etc...) found in a fieldtype.  For each class provide a list of all fieldtypes "with details" using that class.
    * list of all fields "with details"
    * list of all dynamic fields "with details"
       
  Whenever a field type is displayed "with details", show...
    * the description
    * backing class
-   * options (ie: `omitNorms`, `stored`, `positionIncrimentGap`, etc...)
+   * options (i.e.: `omitNorms`, `stored`, `positionIncrimentGap`, etc...)
    * analyzer and/or tokenizer/filter chain if they exist
      * descriptions of each if they exist
-   * A list of the fields that using this fieldtype (with some indication wether they override any options) and a link to their details.
+   * A list of the fields that using this fieldtype (with some indication whether they override any options) and a link to their details.
  
  Whenever a field (or dynamic field) is displayed "with details", show...
    * the description
    * the fieldtype
    * the backing class
-   * options (wether explicit, or inherited from fieldtype)
+   * options (whether explicit, or inherited from fieldtype)
    * analyzer and/or tokenizer/filter chain if they exist
      * descriptions of each if they exist
    * list of any fields that this field copies from
@@ -162, +162 @@

  
  == similarity.jsp ==
  
- Along the same links as `analysis.jsp`, it would be useful if there was a simple URL that helped understand what the registered `Similarity` class was doing.  Each of the methods could be represented by a small form for entering inputs, and the results of hte function calls would be returned.
+ Along the same links as `analysis.jsp`, it would be useful if there was a simple URL that helped understand what the registered `Similarity` class was doing.  Each of the methods could be represented by a small form for entering inputs, and the results of the function calls would be returned.
  
  In the case of `lengthNorm`, both the raw value returned, as well as the value after it has been passed through `decodeNorm(encodeNorm(lengthNorm(...)))` should be returned.
  
@@ -180, +180 @@

  
  When displaying the tokens resulting from "Indexing" analysis, the number of tokens (and the field name) could be passed to `decodeNorm(encodeNorm(lengthNorm(...)))` to display what the lengthNorm would be for documents that had that text as it's whole value.  (this should check `omitNorms` for the specified field of course).
  
- When displaying the the tokens resulting from "Query" analysis, the idf for each Term (and the idf form all of hte terms as a phrase) can be displayed.
+ When displaying the the tokens resulting from "Query" analysis, the idf for each Term (and the idf form all of the terms as a phrase) can be displayed.