At the moment, I have added only a (partial?) table of examples. We did not agree to add any 'encoding' attributes as per Pablo's original PR. See https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_examples
This table probably needs more rows - I suggest implementers look at their code bases and see what they do.
Q: we don't have a proper vocabulary or guideline for populating DV_PARSABLE.formalism - do we need to add something here?
If we think such an attribute is needed, we would need to add it to the DV_ENCAPSULATED class, and push this CR to Release 1.1.0.
Reviewers should have a careful look at the table I added - I am not sure it is correct or complete - I see it as up to implementers to help fill this out. https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_examples
Thomas, should "inline" really be something like "embedded object". For me "inline" refers to text, where here I think you are trying to say that the actual object is embedded in encapsulated, which means that is not a reference by url".
Or maybe don't mention inline/embedded at all and jsut have "reference X", noting that is an URL.
Also URI shouldn't really be URL? Since the URIs should resolve to an actual resource when used in encapsulated.
- yes, 'inline' means 'embedded'. URI is normally understood as a permanently safe identifier that can be resolved to the correct location. The actual URL can change. What we want to store is the reliable reference.
Maybe a stupid question:
The fourth (inline JPG) and fifth (inline JPG, Base64 encoded) row seem to have identical attributes for "media_type" and "size" only the data content is different - how does an implementation know if it is base 64 or binary encoding?
(Above speaking of the table in https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_examples)