Just a suggestion / feedback on something that could be done differently, but the current proposal also works.
Instead of applying the restricted charset (Identifier Rules) to the dictionary keys AND to the name, we could make it more similar to how JSON Schema works today:
- There are no limitation on dictionary key charset and it represents the JSON encoding name (
altnames.json). If this contains restricted chars, it's mandatory to add name for codegen / tools.
- The
altnames.json can be removed, and it's not necessary to use a spec extension just to describe existing JSON / JS structures as they are.
- Tools / codegens will always use
name and fall back to the dictionary key.
Advantages from my view:
- Closer to how JSON Schema works today
- One less concept and one less spec extension to understand
- I think that modeling existing JSON structures is very common, the new identifier name restrictions may only work consistently for greenfield / new models that are created in JSON Structure from start.
Disadvantages:
- Validation of correct JSON Structure document is more complicated, because the regexp validation on dictionary keys is conditional (only has to match regex if no
name is provided).
Just a suggestion / feedback on something that could be done differently, but the current proposal also works.
Instead of applying the restricted charset (Identifier Rules) to the dictionary keys AND to the
name, we could make it more similar to how JSON Schema works today:altnames.json). If this contains restricted chars, it's mandatory to addnamefor codegen / tools.altnames.jsoncan be removed, and it's not necessary to use a spec extension just to describe existing JSON / JS structures as they are.nameand fall back to the dictionary key.Advantages from my view:
Disadvantages:
nameis provided).