A standard should also be open-ended to allow for additions that do not result in altering or violating the standard.
For example, a specification involving a container format (such as a <code class="code">tar</code>) should only focus on "<em class="em">containing</em>".
Having <code class="code">tar</code> support taking pictures with a camera would just be out of scope.
- Additional functionality, such as adding encryption to <code class="code">tar</code>, should be written as a separate standard in addition to the.
+ Additional functionality, such as adding encryption to <code class="code">tar</code>, should be written as a separate additional standard.
</p>
<p class="p">
The specifications defined by the <a href="fll/specifications.html" class="link">Featureless Linux Library</a> provide an example of both <a href="fll/specifications.html#completeness_theorem" class="link">completeness</a> and open-endedness.
This especially means that real standards must be free and open.
</p>
<p class="p">
- A "<em class="em">Living Standard</em>" makes it easy to not follow that standard while claiming that the standard is being folloed.
+ A "<em class="em">Living Standard</em>" makes it easy to not follow that standard while claiming that the standard is being followed.
The extent to which a standard is being followed should be clearly defined.
The word "<em class="em">web</em>" is commonly ambiguously used for standards like <abbr title="Hyper Text Markup Language">HTML</abbr>.
The usage of "<em class="em">web</em>" does not clearly define what standard is being followed.
This results in people not having everything they need to make sound decisions on what to use and where.
- This problem commonly plagues the Internet where many people blame the website developers, or owners, for problems caused by the software being used by the people who are complaining that is actually a problem where both parties are not following the same standard despite that standard having the same name.
+ This problem commonly plagues the Internet where many people blame the website developers, or owners, for problems caused by the software being used by the people who are complaining about some problem.
+ This situation is actually a problem where both parties are not following the same standard despite that standard having the same name.
The "<em class="em">web</em>", after all, is not a standard.
- This is a form of misunderstanding, or perhaps false advertising, via the abuse of "<em class="em">buzz words</em>".
+ This is a common misunderstanding or is, perhaps, false advertising via the abuse of "<em class="em">buzz words</em>".
The use of "<em class="em">buzz words</em>" is cultural problem and a standard cannot solve a cultural problem.
The people in the culture must solve the cultural problem.
- By providing a clear definition of what the standard being followed is and to what extent it is being followed, then the user or the user's tools can make better decisions on how to handle the situation.
- A real standard must not only be free to follow or deviate from, but must the standard being followed must be freely communicated.
+ By providing a clear definition of what the standard being followed is and to what extent it is being followed, then the user or the user's tools can make better decisions.
+ A real standard must not only be free to follow or deviate from, a real standard must be free to communicate and understand.
</p>
</div>
</section>
<strong class="strong">Standards Driven Development</strong> does not work well with a "<em class="em">Living Standard</em>".
Software development using a "<em class="em">Living Standard</em>" results in non-compliant software and possibly non-functional software because the standard is free to change at any point in time.
If, however, the standard is clearly versioned through any means, then any software that is developed to follow that version will work as expected, bugs aside.
- This results in easier to maintain code with a clear stable development track and less potential security issues due to unexpected or undefined behavior that could result from a changing standard.
+ This results in easier to maintain code with a clear stable development track and fewer potential security issues due to unexpected or undefined behavior that could result from a changing standard.
For <strong class="strong">Standards Driven Development</strong>, the deliverables of a project may be clearly defined and understood.
The documentation for projects may be more accurate.
Breaking changes can be more easily avoided.