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
Extensions representation is essentially driven by statically typed implementations
and XML. Both of have troubles with custom key-value objects and force to represent
extensions like a collection. Such representation again forces constraint on collections, unnecessary order, complexity with incidental accessing such attributes and expression in JSON schema.
But for JSON-like data-structures more natural would be use
object representation - just compare:
Problem with polymorphic elements and extensions is solved very nice in json-ld by context.
So, may be we could use json-ld with some constraints/conventions as primary format for FHIR JSON.
Problem
Extensions representation is essentially driven by statically typed implementations
and XML. Both of have troubles with custom key-value objects and force to represent
extensions like a collection. Such representation again forces constraint on collections, unnecessary order, complexity with incidental accessing such attributes and expression in JSON schema.
But for JSON-like data-structures more natural would be use
object representation - just compare:
Notes
Problem with polymorphic elements and extensions is solved very nice in json-ld by context.
So, may be we could use json-ld with some constraints/conventions as primary format for FHIR JSON.
Also Grahame published
manifest
proposal, which is similar solution - http://www.healthintersections.com.au/?p=2626The text was updated successfully, but these errors were encountered: