+ I like to encourage following a standard while simultaneously being free to not follow a standard. + At least so long as one doesn't claim to follow the standard when they don't actual follow that standard. + This article is about my personal opinions on a "Living Standard". + The HTML5 standard is used throughout this article as an example of a "Living Standard". +

+ Once upon a time there were reasonably smart people who made the HTML language. + The browser wars happened and long story short the world ended up with HTML5. + The latest iteration of the HTML standard, HTML5, has been a big improvement in overall but the ball has also been dropped in several ways. + The solution chosen to fix the adoption and compliance problems has been to make the HTML5 specification a "Living Standard". +

+ As a "Living Standard", there no longer is an honest way to know if some software is in compliance. + If a standard may change at any point in time, then how can a "Living Standard" be truly called a standard? + On Tuesday some software might be in compliance, on Wednesday some software might cease to be in compliance, and then on Thursday some software might be in compliance again. + Whether or not such a sudden, and perhaps extereme, would happen is not the concern. + Instead, the concern is is that a "Living Standard" allows for this kind of behavior. + A "Living Standard", for all intents and purposes, is a dead standard. +

2024 / 06 / 14 - A Living Standard is a Dead Standard

+ +

Not a Real Standard

+ +

+ A "Living Standard" is not a real standard. + Sure, a "Living Standard" might be written and may even be highly referenced and used. + But the reality is that the moment the standard changes, that standard is no longer be followed. + This can cause the situation where every software out there uses a different standard that is referenced by the same name. + This, in effect, means that a "Living Standard" is a farce or is a guise of a real standard. +

+ The current situation with HTML5 is one where most of the world does not follow the HTML5 standard but despite this claim that they are. + If the presence of bugs or mistakes are set aside, then anything honestly claiming to follow some standard should actually follow that standard to the degree in which is claimed. + This is not referring to features or other functionality provided in addition to following the standard. + This is a moral or an ethical issue and not a technical issue. +

+ The HTML as a "Living Standard" is the result of incompetence or dishonest intentions by those with direct influence of the HTML standard. + As to the incompetence, there is likely a major failure to understand the actual problems. + The HTML suffers from problems such as lacking completeness, not being well written in many ways, and not strictly being followed in truth. + The use of a "Living Standard" actually embraces these problems rather than providing solutions for them. + The end result of this situation has led to the rise of many work-arounds to the problems through complex solutions such as JavaScript, TypeScript, React, Angular, and so on. +

+ +

Providing a Real Standard

+ +

+ A major part of providing a proper, real, standard is understanding the concept of "a separation of concerns". + A standard should be written within a certain scope of its purpose and not beyond that. + 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 tar) should only focus on "containing". + Having tar support taking pictures with a camera would just be out of scope. + Additional functionality, such as adding encryption to tar, should be written as a separate standard in addition to the. +

+ The specifications defined by the Featureless Linux Library provide an example of both completeness and open-endedness. + The FSS-0005 (Somewhat Basic List) standard provides the syntax on how to read and process text. + This text itself is not defined and there is no taxonomy on what the terms can be used. + This scope of the FSS-0005 (Somewhat Basic List) standard is that of the structure of text. + The open-endedness of the FSS-0005 (Somewhat Basic List) standard is that any taxonomy may be used because the standard does not define this. + The Featurless Make Fakefile standard is then able to take the FSS-0005 (Somewhat Basic List) standard and extend it by defining a taxonomy. + This results in a child standard that does not violate the parent standard. + Anything that supports reading the FSS-0005 (Somewhat Basic List) standard can read the Featurless Make Fakefile standard without every needing to know or understand the Featurless Make Fakefile standard. +

+ A consistent, defined, and meaningful language is another major problem that a real standard must solve. + The multi-lingual situation of the world complicates this but providing definitions greatly helps. + The use of "buzz words" and other out of context uses of a word or phrase is a major problem in this regard. + Take the term "side-effect", for example. + A side effect is essentially an effect in addition to the original intended effect. + This term has been vastly misused in the software programming field to inappropriately refer to a function making changes to state outside of that function. + If a function's main effect is to change state outside of that functions scope, then the software programming field commonly wants to call this main effect, a "side-effect". + This nonsensical and moronic use of the term "side-effect" will lead to hard to follow and hard to understand standards. + Such incorrect use of language should be avoided, even if the incorrect usage is popularized. +

+ The purpose of a standard is often ultimately communication, consistency, exchanging, interchanging, or storing. + Methods of exchanging or interchanging data is actually a form of communication when it comes to software technology. + All ends of the software communication must speak the same language, or standard, to be completely successful. + This means that there must be no restrictions on the ability to communicate and understand a standard. +

+ Thinking that a single standard must be used is a mistake that commonly plagues our current day society. + There can be as many standards as possible so long as all ends of the communication speak the same language. + The situation does become more complicated when there are too many standards to select from, but this is a lesser problem when compared to mistake of the one standard to rule them all concept. + Building the standard to allow for free-form deviations will enhance the standards usability. + This especially means that real standards must be free and open. +

+ A "Living Standard" makes it easy to not follow that standard while claiming that the standard is being folloed. + The extent to which a standard is being followed should be clearly defined. + The word "web" is commonly ambiguously used for standards like HTML. + The usage of "web" 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. + The "web", after all, is not a standard. + This is a form of misunderstanding, or perhaps false advertising, via the abuse of "buzz words". + The use of "buzz words" 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. +

+ +

Standards Driven Development

+ +

+ The software development practice of writing a standard and building software to function around that standard is a practice that I have pioneered as Standards Driven Development. + The Kevux projects and the Featureless Linux Library project are just some of the projects that I practice this software development strategy. + The Standards Driven Development process relies on determine the scope, intent, purpose, and depth of some standard. + This is unlike a "Living Standard" which does not rely on any scope, depth, or planning. + A "Living Standard" embraces the "figure it out as you go" concept. +

+ Standards Driven Development does not work well with a "Living Standard". + Software development using a "Living Standard" 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. + For Standards Driven Development, 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. + Software projects will also be more long term maintainable and more usable in archival, backup, and data recovery purposes when following Standards Driven Development. +

+ If and when a standard needs to be changed, then the software project developers can find the version that they want to support and then develop against that specific version of the standard. + Dealing with users of the software can potentially also be easier in regards to users questioning what is or is not supported. + A standard can always be clearly referenced and users will have more opportunities to know and understand what to expect and what not to expect with some software. +

+ A "Living Standard", on the other hand, has a short life span. + Users will never know if the software project is or is not supposed to provide some functionality. + Debugging and maintaining a project following a "Living Standard" is abysmal. + A project could be completely unusable after an update because of the changes to a "Living Standard". + This would result in "Duct-Tape Programming", which is essentially a bunch of work-around of work-arounds due to not being able to follow a now dead standard. +

+ A "Living Standard" has a short finite life span and is ultimately dead on arrival. +

+ +

+ Kevin Day +