[DOCS-7818] Add info about case-sensitivity of searches (#1610)

content-services/7.3/develop/repo-ext-points/content-model.md

@@ -429,7 +429,7 @@ The following table describes all the parameters that can be used when defining
 |`mandatory`|element (boolean)|`[0..1`]|`true` = when a property is set as mandatory it tells Content Services that the property is required. By default, this is not enforced. Instead, Content Services marks content items with empty mandatory properties with the aspect `sys:incomplete`. This is done so that you can create items that have mandatory properties even if the value of the property is not known at the time of content creation, while still indicating that the property is required (eventually). Mandatory properties will have a `*` next to them in the UI.<br><br>`false` = it is optional and this is the default if this element is not specified.<br><br>The `mandatory` element can also have a `boolean` attribute called `enforced`. If this is set to `true` then you cannot create a node without this property having a value.|<br><br>
 |`multiple`|element (boolean)|`[0..1]`|`true` = this property can have a list of values.<br><br>`false` = only one value can be entered and this is the default if this element is not specified.|
 |`default`|element (any)|`[0..1`]|Default value for this property if the user does not specify any value. The UI input field will be pre-populated with this value.|
-|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization.<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
+|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization. <br><br>_Tokenized searches are case-insensitive, while un-tokenized searches are case-sensitive._<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
 |`constraints`|element|`[0..1]`|Container for property constraints.|
 
 The last thing that is defined in the model are the `aspects`. The definition of an aspect does not differ much from a 

content-services/7.4/develop/repo-ext-points/content-model.md

@@ -429,7 +429,7 @@ The following table describes all the parameters that can be used when defining
 |`mandatory`|element (boolean)|`[0..1`]|`true` = when a property is set as mandatory it tells Content Services that the property is required. By default, this is not enforced. Instead, Content Services marks content items with empty mandatory properties with the aspect `sys:incomplete`. This is done so that you can create items that have mandatory properties even if the value of the property is not known at the time of content creation, while still indicating that the property is required (eventually). Mandatory properties will have a `*` next to them in the UI.<br><br>`false` = it is optional and this is the default if this element is not specified.<br><br>The `mandatory` element can also have a `boolean` attribute called `enforced`. If this is set to `true` then you cannot create a node without this property having a value.|<br><br>
 |`multiple`|element (boolean)|`[0..1]`|`true` = this property can have a list of values.<br><br>`false` = only one value can be entered and this is the default if this element is not specified.|
 |`default`|element (any)|`[0..1`]|Default value for this property if the user does not specify any value. The UI input field will be pre-populated with this value.|
-|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization.<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
+|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization. <br><br>_Tokenized searches are case-insensitive, while un-tokenized searches are case-sensitive._<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
 |`constraints`|element|`[0..1]`|Container for property constraints.|
 
 The last thing that is defined in the model are the `aspects`. The definition of an aspect does not differ much from a 

content-services/latest/develop/repo-ext-points/content-model.md

@@ -429,7 +429,7 @@ The following table describes all the parameters that can be used when defining
 |`mandatory`|element (boolean)|`[0..1`]|`true` = when a property is set as mandatory it tells Content Services that the property is required. By default, this is not enforced. Instead, Content Services marks content items with empty mandatory properties with the aspect `sys:incomplete`. This is done so that you can create items that have mandatory properties even if the value of the property is not known at the time of content creation, while still indicating that the property is required (eventually). Mandatory properties will have a `*` next to them in the UI.<br><br>`false` = it is optional and this is the default if this element is not specified.<br><br>The `mandatory` element can also have a `boolean` attribute called `enforced`. If this is set to `true` then you cannot create a node without this property having a value.|<br><br>
 |`multiple`|element (boolean)|`[0..1]`|`true` = this property can have a list of values.<br><br>`false` = only one value can be entered and this is the default if this element is not specified.|
 |`default`|element (any)|`[0..1`]|Default value for this property if the user does not specify any value. The UI input field will be pre-populated with this value.|
-|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization.<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
+|`index`|element|`[0..1]`|Solr/Lucene index configuration. The indexing behavior for each property can be configured. If we don't configure any indexing behavior, then the default configuration is:<br><br>`<index enabled="true">`<br><br>&nbsp;&nbsp;`<atomic>true</atomic>`<br><br>&nbsp;&nbsp;`<stored>false</stored>`<br><br>&nbsp;&nbsp;`<tokenised>true</tokenised>`<br><br>`</index>`<br><br>Explanation of default index configuration:<br><br>`enabled="true"`: index the value of the property. Setting this to `false` means that the property is not indexed at all and is not part of the index.<br><br> `<atomic>true</atomic>`: atomic is not used when Content Services uses Solr for search. The default value is there to allow the continued use of the built in Lucene indexing engine when customers don't want to, or cannot, switch to Solr. With Solr the index is eventually up-to-date with the database (properties/metadata are stored in the database).<br><br>`<stored>false</stored>`: the property value is not stored in the index. This property is not used with Solr either, all fields are store in the new cached content store on the Solr side.<br><br>`<tokenised>true</tokenised>`: the property value is tokenized when it's indexed, so if the value is "Company Confidential" it will be tokenized into two strings that will be indexed separately, which might not always be what you want. You can also use `false`, which will just tokenize the value as one item. Further on, it also possible to set it to `both`, which means that "Company Confidential", "Company", and "Confidential" will be in the index. The tokenizer is determined by the property type in the data dictionary. This is locale sensitive as supported by the data dictionary, so you could switch to tokenize all your content in for example German. You cannot mix for example German and English tokenization. <br><br>_Tokenized searches are case-insensitive, while un-tokenized searches are case-sensitive._<br><br>There is also another sub-element that can be specified for the `index` element. It is called `facetable` and controls the faceting behavior in Solr as follows:<br><br>`<facetable>true</facetable>`: property is set up properly in Solr for faceting and is really fast, ordered, and sorted.<br><br>`<facetable>false</facetable>`: property is not facetable, that is, you cannot create a facet from this property. In some cases it makes no sense to make a property facetable, for example if it is a unique property. Note that setting facetable to false will not save resources.<br><br>**Unspecified as above (default):** faceting works but not as fast and efficient as when this element is explicitly specified and set to `true`.|
 |`constraints`|element|`[0..1]`|Container for property constraints.|
 
 The last thing that is defined in the model are the `aspects`. The definition of an aspect does not differ much from a