You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's programmatically a bit of a pain to determine what sort of file you're validating/visualizing. Primarily as there is no indicator of what type of content you're processing without referring to schemas.
For example for the initial PR of the VSCode extension, this led to logic like if $schema contains /pattern/ then it's an instantization. This isn't ideal and can quickly fall apart if someone refers to a pattern without this handy indicator.
Programmatically determining the type of file being processed could simplify our validation/visualization flows from a CLI perspective too.
Potential Solutions:
Introduce into the CALM schema the concept of a type - so the JSON files self-describe what they are.
The benefit of having the file names describe what they are documenting would also allow for extra validation to occur - for example if I have a file called .instance.json I know it should have certain elements present.
Names are obviously a discussion point, just wanted to propose what the initial draft could be ( thanks @willosborne for helping with the list! )
The text was updated successfully, but these errors were encountered:
Biased, but I like the second approach more as we discussed during the office hours.
What do people think about the control requirement/evidence part? Do we even want an extension for these domains? I know this was discussed on the call
Could I suggest somehow making it less likely to have a collision on the extensions against other things using the same extensions (e.g. .flow.json)? Something like blah.calm-pattern.json seems like a lot of typing, but maybe a compromise is something like blah.cpattern.json or 'blah.c-pattern.json.
Feature Request
Description of Problem:
It's programmatically a bit of a pain to determine what sort of file you're validating/visualizing. Primarily as there is no indicator of what type of content you're processing without referring to schemas.
For example for the initial PR of the VSCode extension, this led to logic like
if $schema contains /pattern/
then it's an instantization. This isn't ideal and can quickly fall apart if someone refers to a pattern without this handy indicator.Programmatically determining the type of file being processed could simplify our validation/visualization flows from a CLI perspective too.
Potential Solutions:
"calm-type": ["pattern", "pattern-instantiation", ...others ]
.pattern.json
.instance.json
.requirement.json
.evidence.json
.layout.json
.flow.json
The benefit of having the file names describe what they are documenting would also allow for extra validation to occur - for example if I have a file called
.instance.json
I know it should have certain elements present.Names are obviously a discussion point, just wanted to propose what the initial draft could be ( thanks @willosborne for helping with the list! )
The text was updated successfully, but these errors were encountered: