Improve description of DV_ENCAPSULATED encoding variations




Thomas Beale
April 23, 2018, 1:35 PM

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

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.

Thomas Beale
May 3, 2018, 9:33 AM

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.

Pablo Pazos
May 7, 2018, 3:41 AM

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.

Thomas Beale
August 27, 2018, 5:39 PM

- 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.

Erik Sundvall
November 5, 2018, 9:41 AM

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


Thomas Beale

Raised By

Pablo Pazos


Affects versions