Stream: implementers
Topic: base64Binary regex
Drew Torres (Jul 21 2020 at 16:49):
Is there a reason why the regex defined at https://hl7.org/fhir/r4/datatypes.html#base64Binary omits "/"? The regex: (\s([0-9a-zA-Z\+\=]){4}\s)+ The spec then links to https://tools.ietf.org/html/rfc4648, but that does allow for "/". Is this just an error on the regex?
Grahame Grieve (Jul 21 2020 at 21:27):
it's not deliberate
Grahame Grieve (Jul 21 2020 at 21:28):
and I didn't create it myself, but I'm not sure where I got it from. I would have though XML Schema
Drew Torres (Jul 21 2020 at 23:20):
Want me to log a JIRA to correct?
Grahame Grieve (Jul 22 2020 at 00:30):
sure
Alex Vilensky (Jul 22 2020 at 00:35):
Thank you
Drew Torres (Jul 24 2020 at 14:38):
I did log https://jira.hl7.org/browse/FHIR-28139 Should I expect this fixed in R4 as an error correction or r5?
Grahame Grieve (Jul 24 2020 at 20:45):
do you want it to be fixed in R4?
Lee Surprenant (Apr 09 2021 at 19:21):
reviving this old thread to mention that the applied regex from FHIR-28139 doesn't seem quite right to me. i had added my comments there but I think they were missed. i now submitted https://jira.hl7.org/browse/FHIR-31746 to hopefully get a better one
Vassil Peytchev (Apr 09 2021 at 19:49):
Aren't the asterisks there to allow leading and trailing white space?
Jean Duteau (Apr 09 2021 at 20:35):
@Lee Surprenant it's not that your comments were missed, but that Marc and I went with what the resolution was. Marc explicitly reached out to me to see how we should handle your comments and I eventually told him to do what the resolution said. Since I'm not as much of an expert in regex as I'd like, I couldn't figure out if you change was more correct than what was resolved. I totally agree with your new JIRA issue so that we can see if we missed the boat. I'll make that we look at it in one of our upcoming MnM calls.
Jean Duteau (Apr 09 2021 at 20:43):
btw, i've added an alternative regex for base64 in the comments, that I found when I was looking into whether your suggestion was correct or not.
Tilo Christ (Apr 09 2021 at 20:45):
I have commented on the JIRA as to why the second regex is potentially the better one, even though it is very hard to capture all the mandatory subtleties incl. the mandatory padding in a regex.
Lee Surprenant (Apr 09 2021 at 21:23):
Thanks Jean. I'm definitely not attached to the simple one that I included as a comment to FHIR-28139, just rather opposed to the one that got applied because I don't think the * are acting as indended there.
I would note that the one I offered up in FHIR-28139 happens to match the published profile-types.json and so I hope what ends up in the description aligns with what is included in the computable artifact.
Last updated: Apr 12 2022 at 19:14 UTC
