lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ctarg...@apache.org
Subject lucene-solr:branch_7_2: Ref Guide: numerous minor typos ("with out", "ie", "eg") + a couple incorrect link refs
Date Wed, 06 Dec 2017 15:46:38 GMT
Repository: lucene-solr
Updated Branches:
  refs/heads/branch_7_2 5df352f6c -> 108c89e73


Ref Guide: numerous minor typos ("with out", "ie", "eg") + a couple incorrect link refs


Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/108c89e7
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/108c89e7
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/108c89e7

Branch: refs/heads/branch_7_2
Commit: 108c89e73d0dd7c14d16d940ca899137a60faae9
Parents: 5df352f
Author: Cassandra Targett <ctargett@apache.org>
Authored: Wed Dec 6 09:41:33 2017 -0600
Committer: Cassandra Targett <ctargett@apache.org>
Committed: Wed Dec 6 09:46:31 2017 -0600

----------------------------------------------------------------------
 .../src/adding-custom-plugins-in-solrcloud-mode.adoc     |  2 +-
 solr/solr-ref-guide/src/config-api.adoc                  |  2 +-
 .../solr-ref-guide/src/field-properties-by-use-case.adoc |  2 +-
 .../src/field-type-definitions-and-properties.adoc       |  8 ++++----
 solr/solr-ref-guide/src/function-queries.adoc            |  2 +-
 solr/solr-ref-guide/src/json-facet-api.adoc              | 11 +++++------
 solr/solr-ref-guide/src/learning-to-rank.adoc            |  2 +-
 .../src/major-changes-from-solr-5-to-solr-6.adoc         |  2 +-
 solr/solr-ref-guide/src/other-parsers.adoc               |  4 ++--
 solr/solr-ref-guide/src/other-schema-elements.adoc       |  2 +-
 solr/solr-ref-guide/src/request-parameters-api.adoc      |  2 +-
 .../src/solrcloud-autoscaling-overview.adoc              |  2 +-
 solr/solr-ref-guide/src/stream-evaluator-reference.adoc  |  2 +-
 .../src/transforming-result-documents.adoc               |  4 ++--
 solr/solr-ref-guide/src/updating-parts-of-documents.adoc |  4 ++--
 .../using-the-solr-administration-user-interface.adoc    |  3 +--
 16 files changed, 26 insertions(+), 28 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc b/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc
index aace7c7..31ec775 100644
--- a/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc
+++ b/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc
@@ -18,7 +18,7 @@
 
 In SolrCloud mode, custom plugins need to be shared across all nodes of the cluster.
 
-When running Solr in SolrCloud mode and you want to use custom code (such as custom analyzers,
tokenizers, query parsers, and other plugins), it can be cumbersome to add jars to the classpath
on all nodes in your cluster. Using the <<blob-store-api.adoc#blob-store-api,Blob Store
API>> and special commands with the <<config-api.adoc#config-api,Config API>>,
you can upload jars to a special system-level collection and dynamically load plugins from
them at runtime with out needing to restart any nodes.
+When running Solr in SolrCloud mode and you want to use custom code (such as custom analyzers,
tokenizers, query parsers, and other plugins), it can be cumbersome to add jars to the classpath
on all nodes in your cluster. Using the <<blob-store-api.adoc#blob-store-api,Blob Store
API>> and special commands with the <<config-api.adoc#config-api,Config API>>,
you can upload jars to a special system-level collection and dynamically load plugins from
them at runtime without needing to restart any nodes.
 
 .This Feature is Disabled By Default
 [IMPORTANT]

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/config-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/config-api.adoc b/solr/solr-ref-guide/src/config-api.adoc
index 4eaedb2..5220f49 100644
--- a/solr/solr-ref-guide/src/config-api.adoc
+++ b/solr/solr-ref-guide/src/config-api.adoc
@@ -37,7 +37,7 @@ All configuration items, can be retrieved by sending a GET request to the
`/conf
 curl http://localhost:8983/solr/techproducts/config
 ----
 
-To restrict the returned results to a top level section, e.g., `query`, `requestHandler`
or `updateHandler`, append the name of the section to the `/config` endpoint following a slash.
E.g. to retrieve configuration for all request handlers:
+To restrict the returned results to a top level section, e.g., `query`, `requestHandler`
or `updateHandler`, append the name of the section to the `/config` endpoint following a slash.
For example, to retrieve configuration for all request handlers:
 
 [source,bash]
 ----

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/field-properties-by-use-case.adoc b/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
index 92ffe5e..11693d1 100644
--- a/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
+++ b/solr/solr-ref-guide/src/field-properties-by-use-case.adoc
@@ -46,4 +46,4 @@ Notes:
 6. [[fpbuc_6,6]] Term vectors are not mandatory here. If not true, then a stored field is
analyzed. So term vectors are recommended, but only required if `stored=false`.
 7. [[fpbuc_7,7]] For most field types, either `indexed` or `docValues` must be true, but
both are not required. <<docvalues.adoc#docvalues,DocValues>> can be more efficient
in many cases. For `[Int/Long/Float/Double/Date]PointFields`, `docValues=true` is required.
 8. [[fpbuc_8,8]] Stored content will be used by default, but docValues can alternatively
be used. See <<docvalues.adoc#docvalues,DocValues>>.
-9. [[fpbuc_9,9]] Multi-valued sorting may be performed on docValues-enabled fields using
the two-argument `field()` function, e.g. `field(myfield,min)`; see the <<function-queries.adoc#field-function,field()
function in Function Queries>>. 
\ No newline at end of file
+9. [[fpbuc_9,9]] Multi-valued sorting may be performed on docValues-enabled fields using
the two-argument `field()` function, e.g., `field(myfield,min)`; see the <<function-queries.adoc#field-function,field()
function in Function Queries>>. 

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
index 1a7004f..0f64785 100644
--- a/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
+++ b/solr/solr-ref-guide/src/field-type-definitions-and-properties.adoc
@@ -87,10 +87,10 @@ For multivalued fields, specifies a distance between multiple values,
which prev
 
 `autoGeneratePhraseQueries`:: For text fields. If `true`, Solr automatically generates phrase
queries for adjacent terms. If `false`, terms must be enclosed in double-quotes to be treated
as phrases.
 
-`synonymQueryStyle`:: 
-Query used to combine scores of overlapping query terms (i.e. synonyms). Consider a search
for "blue tee" with query-time synonyms `tshirt,tee`.
+`synonymQueryStyle`::
+Query used to combine scores of overlapping query terms (i.e., synonyms). Consider a search
for "blue tee" with query-time synonyms `tshirt,tee`.
 +
-Use `as_same_term` (default) to blend terms, i.e. `SynonymQuery(tshirt,tee)` where each term
will be treated as equally important. Use `pick_best` to select the most significant synonym
when scoring `Dismax(tee,tshirt)`. Use `as_distinct_terms` to bias scoring towards the most
significant synonym `(pants OR slacks)`.
+Use `as_same_term` (default) to blend terms, i.e., `SynonymQuery(tshirt,tee)` where each
term will be treated as equally important. Use `pick_best` to select the most significant
synonym when scoring `Dismax(tee,tshirt)`. Use `as_distinct_terms` to bias scoring towards
the most significant synonym `(pants OR slacks)`.
 +
 `as_same_term` is appropriate when terms are true synonyms (television, tv). Use `pick_best`
or `as_distinct_terms` when synonyms are expanding to hyponyms `(q=jeans w/ jeans\=>jeans,pants)`
and you want exact to come before parent and sibling concepts. See this http://opensourceconnections.com/blog/2017/11/21/solr-synonyms-mea-culpa/[blog
article].
 
@@ -145,4 +145,4 @@ The default values for each property depend on the underlying `FieldType`
class,
 
 A field type may optionally specify a `<similarity/>` that will be used when scoring
documents that refer to fields with this type, as long as the "global" similarity for the
collection allows it.
 
-By default, any field type which does not define a similarity, uses `BM25Similarity`. For
more details, and examples of configuring both global & per-type Similarities, please
see <<other-schema-elements.adoc#similarity,Other Schema Elements>>.
\ No newline at end of file
+By default, any field type which does not define a similarity, uses `BM25Similarity`. For
more details, and examples of configuring both global & per-type Similarities, please
see <<other-schema-elements.adoc#similarity,Other Schema Elements>>.

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/function-queries.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/function-queries.adoc b/solr/solr-ref-guide/src/function-queries.adoc
index 4c9d9d1..5630e23 100644
--- a/solr/solr-ref-guide/src/function-queries.adoc
+++ b/solr/solr-ref-guide/src/function-queries.adoc
@@ -148,7 +148,7 @@ You can quote the term if it's more complex, or do parameter substitution
for th
 * `...&defType=func` `&q=docfreq(text,$myterm)&myterm=solr`
 
 === field Function
-Returns the numeric docValues or indexed value of the field with the specified name. In its
simplest (single argument) form, this function can only be used on single valued fields, and
can be called using the name of the field as a string, or for most conventional field names
simply use the field name by itself with out using the `field(...)` syntax.
+Returns the numeric docValues or indexed value of the field with the specified name. In its
simplest (single argument) form, this function can only be used on single valued fields, and
can be called using the name of the field as a string, or for most conventional field names
simply use the field name by itself without using the `field(...)` syntax.
 
 When using docValues, an optional 2nd argument can be specified to select the `min` or `max`
value of multivalued fields.
 

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/json-facet-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/json-facet-api.adoc b/solr/solr-ref-guide/src/json-facet-api.adoc
index 84388b4..b823d53 100644
--- a/solr/solr-ref-guide/src/json-facet-api.adoc
+++ b/solr/solr-ref-guide/src/json-facet-api.adoc
@@ -299,7 +299,7 @@ By default, the ranges used to compute range faceting between `start`
and `end`
 
 * "lower" all gap based ranges include their lower bound
 * "upper" all gap based ranges include their upper bound
-* "edge" the first and last gap ranges include their edge bounds (ie: lower for the first
one, upper for the last one) even if the corresponding upper/lower option is not specified
+* "edge" the first and last gap ranges include their edge bounds (i.e., lower for the first
one, upper for the last one) even if the corresponding upper/lower option is not specified
 * "outer" the “before” and “after” ranges will be inclusive of their bounds, even
if the first or last ranges already include those boundaries.
 * "all" shorthand for lower, upper, edge, outer
 
@@ -318,8 +318,8 @@ Example:
   categories : {
      type : terms,
      field : cat,
-     domain : { filter : "popularity:[5 TO 10]" } 
-   } 
+     domain : { filter : "popularity:[5 TO 10]" }
+   }
 }
 ----
 The value of `filter` can be a single query to treat as a filter, or a list of filter queries.
 Each one can be:
@@ -397,7 +397,7 @@ Now if we wanted to add a nested facet to find the top 2 authors for each
genre
     field: genre,
     limit: 5,
     facet:{
-      top_authors:{ 
+      top_authors:{
         type: terms, // nested terms facet on author will be calculated for each parent bucket
(genre)
         field: author,
         limit: 2
@@ -441,7 +441,7 @@ And the response will look something like:
           }
         },
         [...]
- 
+
 ----
 
 By default "top authors" is defined by simple document count descending, but we could use
our aggregation functions to sort by more interesting metrics.
@@ -458,4 +458,3 @@ http://yonik.com/solr-facet-functions/
 http://yonik.com/solr-subfacets/
 
 http://yonik.com/percentiles-for-solr-faceting/
-

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/learning-to-rank.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/learning-to-rank.adoc b/solr/solr-ref-guide/src/learning-to-rank.adoc
index 3bbc34d..c165a36 100644
--- a/solr/solr-ref-guide/src/learning-to-rank.adoc
+++ b/solr/solr-ref-guide/src/learning-to-rank.adoc
@@ -554,7 +554,7 @@ Then, configure `DefaultWrapperModel` to wrap `myModel.json`:
 
 `myModel.json` will be loaded during the initialization and be able to use by specifying
`model=myWrapperModel`.
 
-NOTE: No `"features"` are configured in `myWrapperModel` because the features of the wrapped
model (`myModel`) will be used; also note that the `"store"` configured for the wrapper model
must match that of the wrapped model i.e. in this example the feature store called `largeModelsFeatureStore`
is used.
+NOTE: No `"features"` are configured in `myWrapperModel` because the features of the wrapped
model (`myModel`) will be used; also note that the `"store"` configured for the wrapper model
must match that of the wrapped model i.e., in this example the feature store called `largeModelsFeatureStore`
is used.
 
 CAUTION: `<lib dir="/path/to/models" regex=".*\.json" />` doesn't work as expected
in this case, because `SolrResourceLoader` considers given resources as JAR if `<lib />`
indicates files.
 

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc b/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
index 0ebb793..ea4cba1 100644
--- a/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
+++ b/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
@@ -76,7 +76,7 @@ Please review the <<schema-factory-definition-in-solrconfig.adoc#schema-factory-
 
 == Default Similarity Changes
 
-Solr's default behavior when a Schema does not explicitly define a global <<other-schema-elements.adoc#other-schema-elements,`<similarity/>`>>
is now dependent on the `luceneMatchVersion` specified in the `solrconfig.xml`. When `luceneMatchVersion
< 6.0`, an instance of `ClassicSimilarityFactory` will be used, otherwise an instance of
`SchemaSimilarityFactory` will be used. Most notably this change means that users can take
advantage of per Field Type similarity declarations, with out needing to also explicitly declare
a global usage of `SchemaSimilarityFactory`.
+Solr's default behavior when a Schema does not explicitly define a global <<other-schema-elements.adoc#other-schema-elements,`<similarity/>`>>
is now dependent on the `luceneMatchVersion` specified in the `solrconfig.xml`. When `luceneMatchVersion
< 6.0`, an instance of `ClassicSimilarityFactory` will be used, otherwise an instance of
`SchemaSimilarityFactory` will be used. Most notably this change means that users can take
advantage of per Field Type similarity declarations, without needing to also explicitly declare
a global usage of `SchemaSimilarityFactory`.
 
 Regardless of whether it is explicitly declared, or used as an implicit global default, `SchemaSimilarityFactory`
's implicit behavior when a Field Types do not declare an explicit `<similarity />`
has also been changed to depend on the the `luceneMatchVersion`. When `luceneMatchVersion
< 6.0`, an instance of `ClassicSimilarity` will be used, otherwise an instance of `BM25Similarity`
will be used. A `defaultSimFromFieldType` init option may be specified on the `SchemaSimilarityFactory`
declaration to change this behavior. Please review the `SchemaSimilarityFactory` javadocs
for more details
 

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/other-parsers.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/other-parsers.adoc b/solr/solr-ref-guide/src/other-parsers.adoc
index f255863..670aefd 100644
--- a/solr/solr-ref-guide/src/other-parsers.adoc
+++ b/solr/solr-ref-guide/src/other-parsers.adoc
@@ -269,7 +269,7 @@ does _not_ return that document because SpanNearQuery has no good way
to handle
 
 ==== Escaping with Complex Phrase Parser
 
-Special care has to be given when escaping: clauses between double quotes (usually whole
query) is parsed twice, these parts have to be escaped as twice. eg `"foo\\: bar\\^"`.
+Special care has to be given when escaping: clauses between double quotes (usually whole
query) is parsed twice, these parts have to be escaped as twice, e.g., `"foo\\: bar\\^"`.
 
 == Field Query Parser
 
@@ -450,7 +450,7 @@ The Document & Field modeling used in the above examples enumerated
all of the o
 
 But in many cases it can also be possible to drastically simplify the model used.
 
-For example, the same graph shown in the diagram above can be modelled by Solr Documents
that represent each node and know only the ids of the nodes they link to, with out knowing
anything about the incoming links:
+For example, the same graph shown in the diagram above can be modelled by Solr Documents
that represent each node and know only the ids of the nodes they link to, without knowing
anything about the incoming links:
 
 [source,bash]
 ----

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/other-schema-elements.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/other-schema-elements.adoc b/solr/solr-ref-guide/src/other-schema-elements.adoc
index e58f822..d662dce 100644
--- a/solr/solr-ref-guide/src/other-schema-elements.adoc
+++ b/solr/solr-ref-guide/src/other-schema-elements.adoc
@@ -90,6 +90,6 @@ In most cases, specifying global level similarity like this will cause an
error
 
 In the example above `IBSimilarityFactory` (using the Information-Based model) will be used
for any fields of type `text_ib`, while `DFRSimilarityFactory` (divergence from random) will
be used for any fields of type `text_dfr`, as well as any fields using a type that does not
explicitly specify a `<similarity/>`.
 
-If `SchemaSimilarityFactory` is explicitly declared with out configuring a `defaultSimFromFieldType`,
then `BM25Similarity` is implicitly used as the default.
+If `SchemaSimilarityFactory` is explicitly declared without configuring a `defaultSimFromFieldType`,
then `BM25Similarity` is implicitly used as the default.
 
 In addition to the various factories mentioned on this page, there are several other similarity
implementations that can be used such as the `SweetSpotSimilarityFactory`, `ClassicSimilarityFactory`,
etc.... For details, see the Solr Javadocs for the {solr-javadocs}/solr-core/org/apache/solr/schema/SimilarityFactory.html[similarity
factories].

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/request-parameters-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/request-parameters-api.adoc b/solr/solr-ref-guide/src/request-parameters-api.adoc
index ced4f21..4a3dd54 100644
--- a/solr/solr-ref-guide/src/request-parameters-api.adoc
+++ b/solr/solr-ref-guide/src/request-parameters-api.adoc
@@ -118,7 +118,7 @@ Solr ships with many out-of-the-box request handlers that may only be
configured
 
 === Viewing Expanded Paramsets and Effective Parameters with RequestHandlers
 
-To see the expanded paramset and the resulting effective parameters for a RequestHandler
defined with `useParams`, use the `expandParams` request param. E.g. for the `/export` request
handler:
+To see the expanded paramset and the resulting effective parameters for a RequestHandler
defined with `useParams`, use the `expandParams` request param. As an example, for the `/export`
request handler:
 
 [source,bash]
 ----

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc
index de4d708..2c4c433 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc
@@ -98,7 +98,7 @@ You can learn more about Trigger Actions in the section <<solrcloud-autoscaling-
 
 An Autoscaling *listener* can be attached to a trigger. Solr calls the listener each time
the trigger fires as well as before and after the actions performed by the trigger. Listeners
are useful as a call back mechanism to perform tasks such as logging or informing external
systems about events. For example, a listener is automatically added by Solr to each trigger
to log details of the trigger fire and actions to the `.system` collection.
 
-You can learn more about Listeners in the section <<solrcloud-autoscaling-policy-preferences.adoc#solrcloud-autoscaling-policy-preferences,Autoscaling
Listeners>>.
+You can learn more about Listeners in the section <<solrcloud-autoscaling-listeners.adoc#solrcloud-autoscaling-listeners,Autoscaling
Listeners>>.
 
 == Autoscaling APIs
 

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/stream-evaluator-reference.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/stream-evaluator-reference.adoc b/solr/solr-ref-guide/src/stream-evaluator-reference.adoc
index 556ea54..9ebc62b 100644
--- a/solr/solr-ref-guide/src/stream-evaluator-reference.adoc
+++ b/solr/solr-ref-guide/src/stream-evaluator-reference.adoc
@@ -108,7 +108,7 @@ emitted by the analyzer. The `analyze` function can be called on its own
or with
 The expressions below show the various ways in which you can use the `analyze` evaluator.
 
 * Analyze the raw text: `analyze("hello world", analyzerField)`
-* Analyze a text field within a `select` expression. This will annotate the tuples with output
of the analyzer: `select(expr, analyze(textField, analyzerField) as outField)`
+* Analyze a text field within a `select` expression. This will annotate tuples with the output
of the analyzer: `select(expr, analyze(textField, analyzerField) as outField)`
 * Analyze a text field with a `cartesianProduct` expression. This will stream each token
emitted by the analyzer in its own tuple: `cartesianProduct(expr, analyze(textField, analyzer)
as outField)`
 
 == and

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/transforming-result-documents.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/transforming-result-documents.adoc b/solr/solr-ref-guide/src/transforming-result-documents.adoc
index 092aaba..09ae314 100644
--- a/solr/solr-ref-guide/src/transforming-result-documents.adoc
+++ b/solr/solr-ref-guide/src/transforming-result-documents.adoc
@@ -199,7 +199,7 @@ fl=id,source_s:[json]&wt=json
 This transformer executes a separate query per transforming document passing document fields
as an input for subquery parameters. It's usually used with `{!join}` and `{!parent}` query
parsers, and is intended to be an improvement for `[child]`.
 
 * It must be given an unique name: `fl=*,children:[subquery]`
-* There might be a few of them, eg `fl=*,sons:[subquery],daughters:[subquery]`.
+* There might be a few of them, e.g., `fl=*,sons:[subquery],daughters:[subquery]`.
 * Every `[subquery]` occurrence adds a field into a result document with the given name,
the value of this field is a document list, which is a result of executing subquery using
document fields as an input.
 
 Here is how it looks like in various formats:
@@ -250,7 +250,7 @@ Here is how it looks like in various formats:
 
 ==== Subquery Result Fields
 
-To appear in subquery document list, a field should be specified both fl parameters, in main
one fl (despite the main result documents have no this field) and in subquery's one eg `foo.fl`.
Of course, you can use wildcard in any or both of these parameters. For example, if field
title should appear in categories subquery, it can be done via one of these ways.
+To appear in subquery document list, a field should be specified both fl parameters, in main
one fl (despite the main result documents have no this field) and in subquery's one e.g.,
`foo.fl`. Of course, you can use wildcard in any or both of these parameters. For example,
if field title should appear in categories subquery, it can be done via one of these ways.
 
 [source,plain]
 ----

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/updating-parts-of-documents.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/updating-parts-of-documents.adoc b/solr/solr-ref-guide/src/updating-parts-of-documents.adoc
index c15b6ed..3efc00a 100644
--- a/solr/solr-ref-guide/src/updating-parts-of-documents.adoc
+++ b/solr/solr-ref-guide/src/updating-parts-of-documents.adoc
@@ -30,7 +30,7 @@ Atomic Updates (and in-place updates) and Optimistic Concurrency may be
used as
 
 Solr supports several modifiers that atomically update values of a document. This allows
updating only specific fields, which can help speed indexing processes in an environment where
speed of index additions is critical to the application.
 
-To use atomic updates, add a modifier to the field that needs to be updated. The content
can be updated, added to, or incrementally increased if a number.
+To use atomic updates, add a modifier to the field that needs to be updated. The content
can be updated, added to, or incrementally increased if the field has a numeric type.
 
 `set`::
 Set or replace the field value(s) with the specified value(s), or remove the values if 'null'
or empty list is specified as the new value.
@@ -182,7 +182,7 @@ When the client resubmits a changed document to Solr, the `\_version_`
can be in
 
 If the document being updated does not include the `\_version_` field, and atomic updates
are not being used, the document will be treated by normal Solr rules, which is usually to
discard the previous version.
 
-When using Optimistic Concurrency, clients can include an optional `versions=true` request
parameter to indicate that the _new_ versions of the documents being added should be included
in the response. This allows clients to immediately know what the `\_version_` is of every
documented added with out needing to make a redundant <<realtime-get.adoc#realtime-get,`/get`
request>>.
+When using Optimistic Concurrency, clients can include an optional `versions=true` request
parameter to indicate that the _new_ versions of the documents being added should be included
in the response. This allows clients to immediately know what the `\_version_` is of every
documented added without needing to make a redundant <<realtime-get.adoc#realtime-get,`/get`
request>>.
 
 For example:
 

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/108c89e7/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc b/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc
index 4de0282..2860487 100644
--- a/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc
+++ b/solr/solr-ref-guide/src/using-the-solr-administration-user-interface.adoc
@@ -19,11 +19,10 @@
 
 This section discusses the Solr Administration User Interface ("Admin UI").
 
-
 The <<overview-of-the-solr-admin-ui.adoc#overview-of-the-solr-admin-ui,Overview of
the Solr Admin UI>> explains the basic features of the user interface, what's on the
initial Admin UI page, and how to configure the interface. In addition, there are pages describing
each screen of the Admin UI:
 
 * *<<getting-assistance.adoc#getting-assistance,Getting Assistance>>* shows you
how to get more information about the UI.
-* *<<logging.adoc#logging,Logging>>* >shows recent messages logged by this
Solr node and provides a way to change logging levels for specific classes.
+* *<<logging.adoc#logging,Logging>>* shows recent messages logged by this Solr
node and provides a way to change logging levels for specific classes.
 * *<<cloud-screens.adoc#cloud-screens,Cloud Screens>>* display information about
nodes when running in SolrCloud mode.
 * *<<collections-core-admin.adoc#collections-core-admin,Collections / Core Admin>>*
explains how to get management information about each core.
 * *<<java-properties.adoc#java-properties,Java Properties>>* shows the Java information
about each core.


Mime
View raw message