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
Investigate the overlaps and consider switching over to, and extending, JSON Schema. This could be pretty powerful, but also a overcomplicated due to its extensive feature set (e.g. external references).
Really, the best thing about this approach would be type safety and validation. The worst thing would be potential complexity. Some of this complexity could be avoided if a simplified format could be processed into full JSON Schema.
We could then also provide a meta-schema for the field definitions themselves.
Examples of changes
Rough examples of what certain fields types look like now, and what they'd look like with JSON schema.
Before
profile:
type: sectionlabel: Profiledescription: Character profileprofile.name:
type: stringlabel: Namedescription: The character's given or chosen nameprofile.alignment:
type: selectionlabel: Alignmentdescription: The character's general and moral attitudeoptions:
options:
lawfulGood: Lawful GoodneutralGood: Neutral GoodchaoticGood: Chaotic GoodlawfulNeutral: Lawful NeutraltrueNeutral: True NeutralchaoticNeutral: Chaotic NeutrallawfulEvil: Lawful EvilneutralEvil: Neutral EvilchaoticEvil: Chaotic Evil
After
JSON Schema always defines the root, whereas Pragma currently implies one. We can still imply one, we just embed the form fields into the properties of a type: object.
type: objecttitle: Pathfinder Character Sheetdescription: JSON Schema for Pragma forms for the Pathfinder roleplaying game.properties:
profile:
type: objecttitle: Profiledescription: Character profilesproperties:
name:
type: stringtitle: Namedescription: The character's given or chosen namealignment:
type: stringtitle: Alignmentdescription: The character's general and moral attitudeenum: ['lawfulGood', 'neutralGood', 'chaoticGood', 'lawfulNeutral', 'trueNeutral', 'chaoticNeutral','lawfulEvil', 'neutralEvil', 'chaoticEvil']options: # This is where any Pragma-specific data would resideenumLabels: ['Lawful Good', 'Neutral Good', 'Chaotic Good', 'Lawful Neutral', 'True Neutral', 'Chaotic Neutral','Lawful Evil', 'Neutral Evil', 'Chaotic Evil']
It's much more verbose, and introduces the nesting that Pragma's format tries to avoid, but we could find a middle ground that compiles to JSON schema. For example:
profile:
type: objecttitle: Profiledescription: Character profilesprofile.name:
type: stringtitle: Namedescription: The character's given or chosen nameprofile.alignment:
type: stringtitle: Alignmentdescription: The character's general and moral attitudeenum: ['lawfulGood', 'neutralGood', 'chaoticGood', 'lawfulNeutral', 'trueNeutral', 'chaoticNeutral','lawfulEvil', 'neutralEvil', 'chaoticEvil']options: # This is where any Pragma-specific data would resideenumLabels: ['Lawful Good', 'Neutral Good', 'Chaotic Good', 'Lawful Neutral', 'True Neutral', 'Chaotic Neutral','Lawful Evil', 'Neutral Evil', 'Chaotic Evil']
What we avoid here is properties, or in the case of Pragma's current format: children. We instead rely on full paths like profile.alignment to set the expected properties for different objects.
tag, which is usually something like 'pragma-section' or 'pragma-string', could then become JSON Schema's/JSON Editor's format, which could translate to a theme of tag names to decide how to render.
Considering how such schemas might translate to a server-side implementation, however, this falls apart a bit. E.g. type: string and format: datetime, where a server-side representation might just see this instead as a Date type. However, this isn't too much of a problem, as we're specifying a JSON format.
The text was updated successfully, but these errors were encountered:
Pragma's field definition format is similar to JSON Schema and JSON Editor.
Investigate the overlaps and consider switching over to, and extending, JSON Schema. This could be pretty powerful, but also a overcomplicated due to its extensive feature set (e.g. external references).
Really, the best thing about this approach would be type safety and validation. The worst thing would be potential complexity. Some of this complexity could be avoided if a simplified format could be processed into full JSON Schema.
We could then also provide a meta-schema for the field definitions themselves.
Examples of changes
Rough examples of what certain fields types look like now, and what they'd look like with JSON schema.
Before
After
JSON Schema always defines the root, whereas Pragma currently implies one. We can still imply one, we just embed the form fields into the
properties
of atype: object
.It's much more verbose, and introduces the nesting that Pragma's format tries to avoid, but we could find a middle ground that compiles to JSON schema. For example:
What we avoid here is
properties
, or in the case of Pragma's current format:children
. We instead rely on full paths likeprofile.alignment
to set the expected properties for different objects.tag
, which is usually something like'pragma-section'
or'pragma-string'
, could then become JSON Schema's/JSON Editor'sformat
, which could translate to a theme of tag names to decide how to render.Considering how such schemas might translate to a server-side implementation, however, this falls apart a bit. E.g.
type: string
andformat: datetime
, where a server-side representation might just see this instead as aDate
type. However, this isn't too much of a problem, as we're specifying a JSON format.The text was updated successfully, but these errors were encountered: