Minor language tweaks

doc/requirements/sdid.rst

@@ -13,21 +13,19 @@ Overview
 Settings Overview
 -----------------
 
-The settings package is a long-time feature of ARMI. It was made to fill the niche of gathering user input on how the user wanted a case to proceed and what results the user is hoping to produce.
+The settings package is a long-time feature of ARMI. It was made to fill the niche of gathering user input on what should be simulated and what results should be generated.
 
-A good roadmap to understanding the settings system would be to look at the following principle design considerations, going into each one in detail.
+The main design principles for the settings system are:
 
-* Keep the user's experience with settings as simple as possible
+* Keep the user's experience with settings simple
 * Remove setting definitions from code, centralize them, and facilitate definition change
 * Don't break backwards compatibility
-* Improve safety around possible misuses and accidents of the settings
-* Facilitate interactions with the GUI
+* Improve safety around settings errors
 
-Outside of these points the system should exist in a form trimmed of any superfluous functionality to keep it clean and unobtrusive.
 
-Keep the user's experience with settings as simple as possible
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This is the principle design restraint for the settings package. In addition to raw implementation complexity, asking developers and users to relearn any alterations to the existing system counts towards total complexity; deeming migration to an equally complex system not worth the effort without stronger incentives.
+Keep the user's experience with settings simple
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+This is the principle design restraint for the settings package. The settings must be easy to use, human-readable, and not change too often.
 
 
 Reactor Overview
@@ -73,8 +71,8 @@ will only return the current value of the setting stored under ``mySettingName``
 returns the setting object itself. Only more complex relationships with coupled code tools will be concerned with
 how the object itself behaves. A prime example of this is the GUI.
 
-Improve safety around possible misuses and accidents of the settings
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Improve safety around settings errors
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 While simplicity remains a principle concern, some allotment for error prevention has to be allowed. A basic system that can be misused wildly is inherently more complex than one with a little overhead that works to keep nasty surprises at bay.
 
 The settings system is written in a defensive fashion, as it's the most frequent location for possible developer and user misuse. Given this, any method from accessing non-existent settings to trying to supply duplicate settings has been written with fail-fast behavior.
@@ -116,13 +114,11 @@ As mutable objects are encompassed in the list of supported data types, it becam
 
 The customizability of settings
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Yet another error prevention tool is the customizability of individual settings. As mentioned previously, a complete understanding of the complex meaning involved in setting values can't be programmed. However, when the user creates a setting, they have the ability to control default values, valid ranges, and other basic sanity checking parameters.
+Another error prevention tool is the customizability of individual settings. As mentioned previously, a complete understanding of the complex meaning involved in setting values can't be programmed. However, when the user creates a setting, they have the ability to control default values, valid ranges, and other basic sanity checking parameters.
 
-Each setting is intended to present a way of answering a question to the user from the system. For example many settings ask questions like what external code engine to utilize for advanced calculations, or what temperature to apply to a particular component. These questions are not open ended and as such usually have a set of rules surrounding their use like no temperatures below absolute zero, or only code engines specified by the following three strings are valid.
+Each setting is intended to present a way of answering a question to the user from the system. For example, many settings ask questions like what external code engine to utilize for advanced calculations, or what temperature to apply to a particular component. These questions are not open-ended and as such usually have a set of rules surrounding their use like no temperatures below absolute zero, or only code engines specified by the following three strings are valid.
 
-The provided rules for how a setting behaves varies by subtype (i.e. Numeric settings possess valid maximums and minimums, whereas strings can be matched against a set of acceptable values). Given the extensibility of the setting system there is no limitation currently imposed by the system on what rules may apply. Only a basic set of rules currently exists but that has been found to be more than sufficient in modeling developer specifications for settings thus far.
-
-Most of these customized behaviors are directly linked with how the GUI representation of the settings restrict interactions with the user. For instance values outside of the allowable range for numeric settings will reject the change with an immediate reversion to the previously accepted value, or string settings with a restricted set of acceptable values will only display those in a drop down menu.
+The setting system is designed to be extensible, so developers may add further setting validation specific to the settings they add.
 
 
 Reactor Design