Identifier values should be of type string

[kriswest]

Adding a note that id field values in context objects should always be of type string (which unfortunately can't be represented in the generated context types.)

If you use additionalProperties: { type: "string" } optional properties in context types derived from context will not compile (as they are implicitlystring | undefined and there is no way of expressing undefined in JSONSchema. While using unevaluatedProperties: { type: "string" } or patternProperties: { ".+": {type: "string" }} just result in the property value being allowed to be any (i.e. [property: string]: any) as both allow for defined properties to differ and hence the general constraint [property: string]: string would conflict

In short, the documentation is correct and the generated types are as close to correct as they can be with the code generation we use. To do better would require a manual change after code generation.
I think this a minor flaw as each subtype that defines id properties can and should define their type as string (as instrument does here). Hence, this restriction is only really applied to non-standard id entries.

[netlify]

✅ Deploy Preview for fdc3 ready!

Name	Link
🔨 Latest commit	892ae51
🔍 Latest deploy log	https://app.netlify.com/sites/fdc3/deploys/65c2291f5bf1130008b58f76
😎 Deploy Preview	https://deploy-preview-1149--fdc3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[openfin-johans]

Looks good - ship it!