Stream: implementers
Topic: Operation Outcome elements
Grahame Grieve (Jul 12 2016 at 07:23):
referring to GF#9597, FHIR-I approved making these changes today:
OperationOutcome.issue.details --> OperationOutcome.issue.detail
OperationOutcome.issue.dagnostics --> OperationOutcome.issue.dagnostic
Grahame Grieve (Jul 12 2016 at 07:24):
this was done on the basis that our polic is that element names should be singular, not plural. E..g .Patient.name. not Patient.names.
Grahame Grieve (Jul 12 2016 at 07:25):
however, that logic doesn't strictly apply here: both elements are 0..1, not 0..*, and the common english usage would make plural appropriate. - we named them with plural, though they were never anticipated to have cardinality 0..1.
Grahame Grieve (Jul 12 2016 at 07:26):
And, in fact, "diagnostic" sounds positively wrong to me, though "detail" doesn't.
Grahame Grieve (Jul 12 2016 at 07:26):
anyhow, given all that, I don't think that it's worth making a breaking change to those 2 elements
Grahame Grieve (Jul 12 2016 at 07:26):
opinions?
Erich Schulz (Jul 12 2016 at 07:42):
erm what is a diagnostic?
Grahame Grieve (Jul 12 2016 at 07:42):
"diagnostics" - additional information about what went wrong (often, a stack dump)
Erich Schulz (Jul 12 2016 at 07:43):
it's an adjective isnt it ?
Erich Schulz (Jul 12 2016 at 07:43):
oh, so not like "diagnostic laparotomy" then...
Grahame Grieve (Jul 12 2016 at 07:43):
no.
Grahame Grieve (Jul 12 2016 at 07:44):
that's probably why it sounds wrong to me - I'm used to using diagnostic as an adjective like that
Erich Schulz (Jul 12 2016 at 07:44):
mmm... "error_report" ?
Erich Schulz (Jul 12 2016 at 07:44):
"log"?
Erich Schulz (Jul 12 2016 at 07:45):
"detailed_details" ;-) ?
Grahame Grieve (Jul 12 2016 at 07:45):
if we have to rename it. I'd rather not though. spruiously breaking people's code. at least, that's my personal opinion..
Erich Schulz (Jul 12 2016 at 07:46):
and taking away an s wont break code?
Erich Schulz (Jul 12 2016 at 07:47):
btw did you mean to type OperationOutcome.issue.details --> OperationOutcome.issue.details above?
Grahame Grieve (Jul 12 2016 at 07:49):
the proposal is to remove an s. It will break code, for no value. I want to revisit the decission, but I'm seeing what other people think
Erich Schulz (Jul 12 2016 at 07:50):
it just that's not what you typed...
Grahame Grieve (Jul 12 2016 at 07:51):
no, you're right. typo. I've changed it now
Lloyd McKenzie (Jul 12 2016 at 13:24):
Are there any other places we have elements with a trailing s?
Igor Sirkovich (Jul 12 2016 at 14:49):
I cannot see any benefit of these changes and I agree that it's not a good idea to make breaking changes for no apparent value.
John Moehrke (Jul 12 2016 at 14:57):
we are in the STU phase, now is the time when people better be expecting breaking changes for good or quality reasons.
Lloyd McKenzie (Jul 12 2016 at 14:58):
The only "good" reason for making this change is if implementers are generally expecting there to be no "s" and these elements are the only exceptions.
Igor Sirkovich (Jul 12 2016 at 15:12):
John, this is what we are questioning: is there a good or quality reason to make a change that would have high cost to all existing implementations? There is a cost even if implementations expect breaking changes, especially for an OperationOutcome, a maturity 2 resource that is being used by everyone.
Lloyd McKenzie (Jul 12 2016 at 17:10):
There are 23 places where a name is expressed as a plural (adding in s). However, only 4 places where repeating elements are expressed as plurals. My leaning is to require change for only the latter, because those will clearly be confusing when you have individual repetition items in the instance that contain one repetition but are named as though they contain multiple.
Lloyd McKenzie (Jul 12 2016 at 17:11):
I'm going to submit tracker items for the plural ones I found (except for "notes" which already has an associated warning)
Lloyd McKenzie (Jul 12 2016 at 17:19):
(So I'm happy with us reversing this change request)
Anand Mohan Tumuluri (Jul 12 2016 at 17:51):
OperationOutcome serves as an important API contract, returned from multiple error scenarios on the server side and used in multiple error handlers on the client side. I don't think that this change provides any value while at the same time has a downside in terms of amount of change needed. Please consider the significant adoption that FHIR received before approving this change.
Grahame Grieve (Jul 12 2016 at 19:36):
Agree with Lloyd. We should only focus on repeating elements. I won't execute this change; we can revisit it in committee next week
Lloyd McKenzie (Jul 12 2016 at 20:45):
Have you re-opened it or should I?
Grahame Grieve (Jul 12 2016 at 20:56):
I've reopened it
Last updated: Apr 12 2022 at 19:14 UTC
