docs(docs): add subgraph KV requirements - #85
knithishQIPL wants to merge 1 commit into
Conversation
0ec76c0 to
542d72b
Compare
Capture the agreed requirements and implementation design for the Subgraph Key Configurator. Signed-off-by: Kandepi Nithish <knithish@qti.qualcomm.com>
542d72b to
00e7a12
Compare
| selecting or deselecting all currently filtered keys. Deselecting a key | ||
| shall remove its selected value from the candidate. | ||
| - **FR-SGKV-26:** A selected key shall have at most one selected value. A key | ||
| without a selected value shall not contribute a KV pair to the candidate. |
There was a problem hiding this comment.
isn't this an error that should be handled immediately? will we allow the user to select a key but not a value and still proceed?
| - **FR-SGKV-28:** The Selection Panel shall support sorting keys and values by | ||
| identifier or name. Sorting and filtering shall not change the candidate. | ||
| - **FR-SGKV-29:** Panel-originated candidate text shall use graph-key | ||
| definition order, rather than the order in which the user selected keys. |
There was a problem hiding this comment.
for panel originated subgraphs, SGKVs already exist and the selection panel should be pre-populated with them based on the selections, right? does this requirement talk about the key definition order after a user adds a new key?
| candidate. | ||
| - **FR-SGKV-36:** The Editor shall support a mixed continuation: complete | ||
| Key Value pairs followed immediately by Value Only tokens. Each Value Only | ||
| token shall resolve only against keys unused by the Key Value prefix. |
There was a problem hiding this comment.
so something like DeviceRX: Speaker + Instance_1 can be supported? What if a value is supported in multiple keys (this is a real possibility with other platforms)?
| - **FR-SGKV-60:** A selected subgraph with no stored vectors shall show the | ||
| empty state. A non-empty canonical collection with no filter matches shall | ||
| be represented as no matching vectors, not as no stored vectors. | ||
| - **FR-SGKV-61:** EC vectors shall be visually distinguishable from non-EC |
There was a problem hiding this comment.
visually distinct how? an icon? different colored text? italicized? would be good to clarify though this is probably an implementation detail.
| - **FR-SGKV-62:** The Add KV Vector controls shall be available only when | ||
| graph-key definitions are ready. If definitions cannot be loaded, opening a | ||
| new Add candidate shall not alter the stored vectors or the current | ||
| candidate. |
There was a problem hiding this comment.
agreed but what about the error scenario where definitions cannot be loaded? will the user know that something is wrong when they click Add?
| the Add controls. | ||
| - **FR-SGKV-65:** The vector list, Add Editor, suggestion popup, key list, and | ||
| value lists shall use vertical scrolling when needed and shall not require | ||
| horizontal scrolling for normal interaction. |
There was a problem hiding this comment.
can horizontal scrolling be avoided for a long KV? is this feasible?
| @@ -0,0 +1,891 @@ | |||
| # Subgraph Key Configurator: Low-Level Design | |||
|
|
|||
| **Status:** Draft | |||
There was a problem hiding this comment.
rename file to design.md (folder already indicates the scope) and get rid of the status since it will get committed/merged only after the status changes to Final/Ready/Frozen.
2 participants
Define the agreed scope and behavior for the Subgraph Key Configurator.