WIP: publishing metadata document schema #318
Conversation
| } | ||
| } | ||
| }, | ||
| "connect": { |
There was a problem hiding this comment.
Should this be nested inside a generic container, such that other (theoretical) consumers could add their own settings objects? In general, do we allow attributes that are not declared in this schema (I assume so), and where do we document how consumers should interpret this (i.e., this is the spec, but you aren't prevented from looking for additional fields)?
There was a problem hiding this comment.
Currently, this schema does not set additionalAttributes: true anywhere, because doing so allows a wide range of invalid constructs and typos to pass validation. We can update the schema as features are added to the deployment servers.
Since we only have 2 supported deployment servers, I was intending to give each one a named section for server-type-specific attributes. These sections would be specified in the schema like any other, but ignored by other types of servers. It's reasonable to group them under a parent heading.
…ient into mm-metadata-schema
mmarchetti
requested review from
dotNomad,
kgartland-rstudio,
sagerb and
tdstein
as code owners
|
Q: should we produce a subset schema containing only what's currently supported by the client? That would allow us to differentiate what's a draft for review (easy and cheap to change) from what has code behind it (more expensive to change). |
This sounds like a good change to me. |
Map schema content types to Connect ones
For discussion, a JSON Schema of what it would look like to formalize the options and settings required to publish content to Connect et al. such that it could be checked into source control and drive publishing.