Stream: implementers
Topic: Empty files
Lloyd McKenzie (Mar 01 2021 at 17:02):
Is it ever valid to send an empty (0-byte) file in FHIR? Is there a way to base-64 encode a zero-byte file that won't result in a zero-length string (which is prohibited according to FHIR's rules)?
Eric Prud'hommeaux (Mar 01 2021 at 17:05):
I assume every resource which has a 0 min cardinality on its properties has at least some finite size in every representation (XML, JSON, Turtle)
Eric Prud'hommeaux (Mar 01 2021 at 17:06):
Are you talking about some non-Resources?
Josh Mandel (Mar 01 2021 at 17:07):
I was thinking maybe Lloyd means stuff like Attachment.data?
Eric Prud'hommeaux (Mar 01 2021 at 17:07):
makes sense
Eric Prud'hommeaux (Mar 01 2021 at 17:08):
why is a zero-length string prohibited?
Eric Prud'hommeaux (Mar 01 2021 at 17:09):
are you just supposed to elide the property rather than provide an empty value (or uses some other null form)?
Eric Prud'hommeaux (Mar 01 2021 at 17:09):
(sort of a meta model rule)
Josh Mandel (Mar 01 2021 at 17:10):
Spec says:
Leading and Trailing whitespace is allowed, but SHOULD be removed when using the XML format. Note: This means that a string that consists only of whitespace could be trimmed to nothing, which would be treated as an invalid element value. Therefore strings SHOULD always contain non-whitespace content
Josh Mandel (Mar 01 2021 at 17:11):
And the regex says:
Regex: [ \r\n\t\S]+
Eric Prud'hommeaux (Mar 01 2021 at 17:12):
which makes containing a 0-byte attachment illegal
Josh Mandel (Mar 01 2021 at 17:14):
Well, it makes populating data illegal, but you could omit data and populate Attachment.size as `0 assuming you don't read the following comment too pedantically:
The number of bytes is redundant if the data is provided as a base64binary, but is useful if the data is provided as a url reference.
Eric Prud'hommeaux (Mar 01 2021 at 17:14):
right, undermines the "is redundant" assertion
Josh Mandel (Mar 01 2021 at 17:15):
This is a pretty annoying "special case", but... may be not a huge problem IRL.
Eric Prud'hommeaux (Mar 01 2021 at 17:16):
i'm trying to imagine a scenario where i'd want to say that something is "". haven't come up with it yet, but seems pretty reasonable
John Moehrke (Mar 01 2021 at 17:36):
We have use-cases in XDS for this... so it frustrates me that someone added that comment to attachment.size. Specifically we have use-cases where the bits have not yet been assembled. The DocumentReference is a promise to make the described document (metadtata found in the DocumentReference)... Deferred Creation... or On-Demand
Lloyd McKenzie (Mar 01 2021 at 17:46):
I raise the issue because I was applying a technical correction previously agreed to that allows for a completely empty Parameters instance. It dawned on me that zero-byte files are a thing and was wondering whether we needed to make a similar exception for them. Omitting the content and sending a zero-size seems reasonable to me. Is that worth noting in the usage notes for the Attachment data type?
John Moehrke (Mar 01 2021 at 17:58):
I think so. What comes up next is what to do with the hash element. In the IHE case we leave hash be blank to explain that we are describing something that will eventually have a size and hash. But if you really have a zero length file, then the hash value would be "da39a3ee5e6b4b0d3255bfef95601890afd80709".. not an unreasonable distinction between actually zero size, and currently zero size.
Lloyd McKenzie (Mar 01 2021 at 18:26):
Can you explain more what IHE does @John Moehrke? Do you have Attachment.url and no Attachment.data or do you have neither? If you just have a URL, I would omit size and hash if you're going to generate it on-the-fly. Setting size to zero would not communicate that "we're going to generate this on the fly". (If you want to say that, you'd need an extension.)
John Moehrke (Mar 01 2021 at 18:34):
IHE (MHD) always uses .url. and forbids .data. in the case I described above the .url is populated. The use of size of zero has been used for decades.
John Moehrke (Mar 01 2021 at 18:36):
I don't disagree that some other signal should be provided. The use-case has really not been fully designed in MHD, as the community has not asked that it be used. However there is known use of zero as the signal.
Lloyd McKenzie (Mar 01 2021 at 22:16):
It might be a known use, but I'd object to encoding that use into the spec (or even crafting language to allow for it). If the size says 0, the appropriate interpretation of that is "the file is an empty file", not "the file is going to be generated".
John Moehrke (Mar 01 2021 at 22:19):
understand. just pointing out reality.
John Moehrke (Mar 01 2021 at 22:20):
I would agree that if I saw size of zero, I should not try to pull the content.. but if I did pull it, that should not be seen as a error.
John Moehrke (Mar 01 2021 at 22:21):
we do want that the normal expectation is that if you pull content, and that there is a declared size and hash, that if size or hash are different; that should be seen as an integrity failure.. right?
John Moehrke (Mar 01 2021 at 22:23):
thus I would agree that the right interpretation of size of zero is that getting the URL content or undecoding the .data should result in a zero length file.
John Moehrke (Mar 01 2021 at 22:23):
If hash is populated, then the resulting file better hash to that value.
John Moehrke (Mar 01 2021 at 22:24):
thus, i would agree that unpopulated size (and/or hash) is the right way to say indeterminant.
John Moehrke (Mar 01 2021 at 22:25):
consumers choice if they decide to validate size or hash. they are not compelled to validate them (by core spec)
Lloyd McKenzie (Mar 01 2021 at 22:36):
Agree. You're free to pull it. When the content isn't zero, the default assumption would be that the content has changed since the reference was made.
Last updated: Apr 12 2022 at 19:14 UTC
