From 5b54553bb82fa9d334d4a1a69d2c319777c89100 Mon Sep 17 00:00:00 2001 From: Jeremy LaCivita Date: Wed, 10 Jul 2024 11:56:03 -0400 Subject: [PATCH] fix: Clarified should definition --- requirements/specifications/index.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/requirements/specifications/index.md b/requirements/specifications/index.md index 11948d690..e6da4a553 100644 --- a/requirements/specifications/index.md +++ b/requirements/specifications/index.md @@ -44,12 +44,14 @@ A capability with the level set to `"should"` **SHOULD** be supported. A capability with the level set to `"could"` **COULD** be supported. #### 3.1.1. Should vs Could -This section is non-normative. +This section is non-normative and does not denote any requiements. "Should" means that not supporting a capability has a detremental impact on a Firebolt platform, and care should be taken when deciding not to support a `"should"` capability. For example, a capability supporting HDMI outputs would likely be assigned a level of `"should"`, since most STB devices have HDMI outputs, while most TV devices do not. +If a capability has a level of `"should"` and the device exposes the functionality in question through hardware or software, then it should either be treated as a `"must"` or a really good reason should exist for why it was not implemented. + If a device has HDMI output ports, then it probably should implement this capability. While a device w/out HDMI output ports does not need to. "Could" means that this API is truly optional, for example a capability to expose the postal code of the device might be assigned a `level` of `"could"` since Firebolt platforms can justifiably opt not to support this.