Should we remove the requirement on properties with default values ?
@IsakNaslundBh 已经在做这个了。
开始于 2025年9月3日。
评估
这个 Issue 还没有评估数据。
描述
In the BHoM_UI, users are only required to provide properties that don't have a default value. Considering that the JSON schemas are meant to be used with external partners that don't necessarily have the exact same set of properties as the BHoM, it would be great to do something similar. That way, they can provide only the properties that are relevant within their own environment without having to handle the potential extra richness/complexity that the BHoM might offer.
Here's an example of what I mean. Here's our current schema for a Line:
{
"$id" : "https://raw.githubusercontent.com/BHoM/BHoM_JSONSchema/develop/Geometry_oM/Line.json",
"title" : "Line",
"type" : ["object", "null"],
"description" : "Line: A straight segment in space defining the shortest distance between two points in three-dimensional Euclidean geometry.\nThe Vector from Start to End defines the Line direction, which can be important for some applications.",
"properties" : {
"Start" : {
"$ref" : "https://raw.githubusercontent.com/BHoM/BHoM_JSONSchema/develop/Geometry_oM/Point.json"
},
"End" : {
"$ref" : "https://raw.githubusercontent.com/BHoM/BHoM_JSONSchema/develop/Geometry_oM/Point.json"
},
"Infinite" : {
"type" : "boolean",
"description" : "Defines the Line as a ray of infinite extents in both directions"
},
"_t" : {
"type" : ["string", "null"],
"description" : "Optional type disciminator.",
"const" : "BH.oM.Geometry.Line"
},
"_bhomVersion" : {
"type" : ["string", "null"],
"description" : "Optional version of BHoM used as part of automatic versioning and schema upgrades."
}
},
"required" : ["Start", "End", "Infinite"]
}
This means that this would fail the validation as it doesn't contain the Infinite property:
{
"_t": "BH.oM.Geometry.Line",
"Start": {
"_t": "BH.oM.Geometry.Point",
"X": 1,
"Y": 2,
"Z": 3
},
"End": {
"_t": "BH.oM.Geometry.Point",
"X": 1,
"Y": 2,
"Z": 3
},
"_bhomVersion": "8.1"
}
My issue here is that the BHoM Line would actually be created successfully from the above. So we are enforcing additional constrains that are not a reflection of that would actually work in practice.
I understand that we want to protect the user from incorrectly naming properties. But would it be possible to have warnings instead of errors on properties from the json that are not found on the BHoM object itself? This is what we do in the BHoM_UI and it works quite well that way, providing the best of both worlds.
- 主要语言
- C#
- 星标
- 0
- 派生
- 0
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
BHoM/JSONSchema_Toolkit 的其他 Issue
-
type:feature
难度 5/5 一周以上 新手友好度 25/100
查看 BHoM/JSONSchema_Toolkit 的全部 Issue
相似的 Issue
-
documentation
难度 1/5 1-3 小时 新手友好度 62/100
-
bug misleading tooling trivial
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
Docs example projects pinned to a literal library version instead of 3.*可能已有人在做 @DaveSkender 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
facioquo/stock-indicators-dotnet#2372 ·
维护者通常 1 天内回复
-
[Docs] officecli-docx SKILL.md still describes `\n` as a soft line break after #262可能已有人在做 @giprime 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
Facepunch/sbox-public#12097 ·
维护者通常 2 天内回复