DRS preference in File profile #60
Conversation
🚀 IG Site Preview DeployedLatest commit: 6936d85 |
There was a problem hiding this comment.
Can you make a separate profile, DRS File, which is a child of the NCPI File. Also, can you slice it as "open ended" so that the first content member is required to be a DRS url, but subsequent ones could be something else (i.e. require a DRS id, but optionally allow other URLs in addition)
input/fsh/modules/files.fsh
Outdated
| * content ^slicing.discriminator.type = #pattern | ||
| * content ^slicing.discriminator.path = "code" | ||
| * content ^slicing.rules = #openAtEnd | ||
| * content ^slicing.ordered = false |
There was a problem hiding this comment.
I'm not sure we need slicing at this point since we are fine with regular attachments.
There was a problem hiding this comment.
Right now we have:
* content.attachment.url 1..1 /*Location uri*/
* content.attachment.url ^short = "The URI at which this data can be accessed"
and this made me think there was only one attachment url you could make, thus why I tried doing the slicing. But content is 1..* which inherently means one could attach more than one. Do you want to change how we write the profile or do you think it's self-explanatory?
There was a problem hiding this comment.
So, the tricky part is that content is an array of 1 or more things, each of which will contain one attachment. Each of those attachments must have 1 and only 1 URL. It is a bit confusing, but it does allow multiple URLs, but only because you can have more than one thing inside the content array.
input/fsh/modules/files.fsh
Outdated
| * content[DRS].attachment only DRSAttachment | ||
| //* content[DRS].profile only | ||
| * content[Other].attachment only Attachment |
There was a problem hiding this comment.
I believe you can leave the Other slice out. I believe the open at end is sufficient for allowing other types of attachments in addition to the DRS one(s).
input/fsh/modules/files.fsh
Outdated
| * content ^slicing.discriminator.path = "code" | ||
| * content ^slicing.rules = #openAtEnd | ||
| * content ^slicing.ordered = false |
There was a problem hiding this comment.
I believe it would be better if we could state that the DRS Attachment URI will always be the first. So, this should be set to true.
input/fsh/modules/files.fsh
Outdated
| * content ^slicing.discriminator.type = #pattern | ||
| * content ^slicing.discriminator.path = "code" | ||
| * content ^slicing.rules = #openAtEnd | ||
| * content ^slicing.ordered = false |
There was a problem hiding this comment.
So, the tricky part is that content is an array of 1 or more things, each of which will contain one attachment. Each of those attachments must have 1 and only 1 URL. It is a bit confusing, but it does allow multiple URLs, but only because you can have more than one thing inside the content array.
Motivation
Make DRS file types the preferred attachment type for the File profile and send out a warning if the attachment URI is not DRS.
Approach
Adapt the DRSattachment profile to make DRS preferred but not strictly required.