Stream: shorthand
Topic: example FSH DocumentReference with a Binary
John Moehrke (Jan 13 2021 at 16:57):
DocumentReference.content.attachment.url can point at a Binary.. but I can't figure out how to get Sushi to like that. It seems to think that because the element is url datatype that it can't contain a Reference. but it can.
Chris Moesel (Jan 13 2021 at 19:50):
SUSHI does require url datatypes to be set to a URL (e.g., a string URL). Are you trying to set it using something like Reference(MyBinary) -- and expecting it to resolve to relative path Binary/MyBinaryId? I can see why you would want that to work, but the trouble is that the only hint we have that it might be a valid approach is in the narrative content about Attachment.url. To support this in FSH/SUSHI, we'd need to make it valid to use Reference(...) for all url types. Maybe that's fine -- and something we should consider -- but for now it's not supported; so you'll need to just put "Binary/MyBinaryId".
John Moehrke (Jan 13 2021 at 19:53):
I feared that would happen... yes the intention was that sometimes .url would be manipulated like a Reference.reference, but sometimes it would be a natural url.
Elliot Silver (Jan 13 2021 at 21:22):
It would be great to have a Url() function just like the Canonical() function. And also to be able to compose urls, so I can do siteurl + resourceId.
John Moehrke (Jan 13 2021 at 23:21):
so.,.. is it possible to get this fix into the this release of sushi too?
John Moehrke (Jan 13 2021 at 23:23):
it is especially important for examples of the MHD Provide Document Bundle transaction which is a Transaction Bundle with a List(submissionset) + some DocumentReference(s) with their Binary(s)... thus in the bundle it needs to be appropriate bundle references, that the server fixes up to server side url references...
Chris Moesel (Jan 13 2021 at 23:26):
No, I don't think this will make it into the release. For one, it's actually a change to the FSH spec itself (or at least a looser interpretation of it). So we probably need to think on it a bit more.
Is there a reason you can't just put in the relative URLs as strings? You should know the type and id at authoring time, so isn't it just setting the url to {Type}/{id} (for whatever type/id you're referring to)?
John Moehrke (Jan 13 2021 at 23:27):
I will try that. but I think they are expecting the fullUrl value is used... not sure, will need to try some stuff
John Moehrke (Jan 13 2021 at 23:28):
this is where we need the reference servers to speak up on how they implemented it. There was discussion with them long time ago.
Chris Moesel (Jan 13 2021 at 23:41):
I don't think I understand how one would arrive at the full URL value from a simple Reference anyway (using SUSHI). I don't think there is anyway for SUSHI to know what the base URL should be for an instance (unless the author specifically provides it).
John Moehrke (Jan 13 2021 at 23:44):
no, in the bundle the DocumentReference.content.attachment.url would contain the same value that Bundle.entry[x].fullUrl for the entry the Binary is in.
John Moehrke (Jan 13 2021 at 23:50):
see this xml example https://github.com/usnistgov/asbestos/blob/master/asbestos-mhd/src/test/resources/gov/nist/asbestos/mhd/translation/shared/bundle.xml
Chris Moesel (Jan 14 2021 at 00:10):
OK, right. But we can't translate that into a general behavior that FSH/SUSHI should follow. That's some very specific behavior there (needing to know to search for the entry that contains the matching Binary and then take the URL from the entry's fullUrl field). That's not like anything that FSH currently supports.
Last updated: Apr 12 2022 at 19:14 UTC
