Stream: implementers
Topic: Proposal to drop SearchParameter.xpath and rename xpathUsage
Lloyd McKenzie (Dec 06 2021 at 21:43):
FHIR#32530 proposes dropping both, but we've determined xpathUsage needs to be retained. However, the name is misleading as the element has nothing to do with XPath at all. Obviously, this has been long-implemented, but in practice only a few systems work with SearchParameter at this level. Would we be willing to rename it for clarity long term or do we want xpath to hang around in the name even though xpath is no longer used by anyone?
Lloyd McKenzie (Dec 06 2021 at 21:45):
@James Agnew @Alexander Zautke @Paul Church @nicola (RIO/SS) @Lee Surprenant @Peter Jordan @Michael Lawley @Brian Postlethwaite @Grahame Grieve (feel free to add others you think might care.)
Paul Church (Dec 06 2021 at 21:59):
I would support renaming it to something generic so if we ever move on from fhirpath expressions to the next shiny object it will still be meaningful.
James Agnew (Dec 06 2021 at 22:01):
^ agreed
Paul Church (Dec 06 2021 at 22:06):
Also this really doesn't seem like the "kind" of field where backward compatibility is an issue. I assume the registry of search parameters is regenerated per release, and custom search parameters are pretty implementation dependent if they're supported at all.
Grahame Grieve (Dec 06 2021 at 23:00):
I'm ok with this change. In general, I agree with Paul that it's not something that particularly matters for backwards compatibility as compared to other fields, and I agree that xPathUsage is quite deceptive a name for what it is
Grahame Grieve (Dec 06 2021 at 23:00):
expressionUsage
nicola (RIO/SS) (Dec 06 2021 at 23:59):
Absolutely agree, i think, even xml format support is obsolete ;)
Peter Jordan (Dec 07 2021 at 02:12):
OK with me.
Michael Lawley (Dec 07 2021 at 06:45):
I'm supportive too
Lee Surprenant (Dec 07 2021 at 12:50):
+1 from me. probably stating the obvious, but we'd also want to update the definition for other to remove the xpath reference:
other Other The interpretation of the xpath statement is unknown (and can't be automated).
Alexander Zautke (Dec 07 2021 at 13:28):
Agree, no issue from our side.
Grahame Grieve (Dec 14 2021 at 23:30):
some analysis of all published IGs:
Grahame Grieve (Dec 14 2021 at 23:30):
-- v1.0---------------------
distance n/a nearby normal phonetic
reference 0 / 0 0 / 0 0 / 0 284 / 0 0 / 0
date 0 / 0 0 / 0 0 / 0 81 / 0 0 / 0
number 0 / 0 0 / 0 0 / 0 6 / 0 0 / 0
quantity 0 / 0 0 / 0 0 / 0 4 / 0 0 / 0
string 0 / 0 2 / 0 0 / 0 117 / 0 4 / 0
composite 0 / 0 8 / 0 0 / 0 0 / 0 0 / 0
uri 0 / 0 0 / 0 0 / 0 33 / 0 0 / 0
token 1 / 0 1 / 0 1 / 0 363 / 2 0 / 0
-- v3.0---------------------
distance n/a nearby normal phonetic
reference 0 / 0 0 / 3 0 / 0 425 / 5 0 / 0
date 0 / 0 0 / 0 0 / 0 112 / 2 0 / 0
number 0 / 0 0 / 0 0 / 0 9 / 0 0 / 0
quantity 1 / 0 0 / 0 0 / 0 9 / 0 0 / 0
string 0 / 0 0 / 0 0 / 0 163 / 2 2 / 0
composite 0 / 0 0 / 0 0 / 0 12 / 1 0 / 0
uri 0 / 0 0 / 0 0 / 0 47 / 0 0 / 0
token 0 / 0 0 / 0 1 / 0 464 / 6 0 / 0
-- v4.0---------------------
n/a nearby normal phonetic
date 0 / 11 0 / 0 113 / 18 0 / 0
reference 0 / 36 0 / 0 476 / 41 0 / 0
special 1 / 0 1 / 0 0 / 0 0 / 0
number 0 / 0 0 / 0 7 / 0 0 / 0
quantity 0 / 0 0 / 0 27 / 0 0 / 0
string 0 / 18 0 / 0 139 / 12 3 / 0
composite 0 / 0 0 / 0 46 / 0 0 / 0
uri 0 / 0 0 / 0 45 / 0 0 / 0
token 0 / 37 0 / 0 542 / 53 0 / 0
Grahame Grieve (Dec 14 2021 at 23:30):
first number is core, second number is IG
Grahame Grieve (Dec 14 2021 at 23:31):
.. something wrong there... there is some specials...
Josh Mandel (Dec 14 2021 at 23:37):
"n/a" means SearchParameter.xpathUsage is not set? Interesting that IGs are lax about this where the core spec is not --- suggests we're applying stricter editorial checks in Core?
Josh Mandel (Dec 14 2021 at 23:39):
All the IG "N/A" are presumably all "normal" (unless something extra interesting is being done in IGs).
Grahame Grieve (Dec 15 2021 at 01:25):
oh - I know. I missed lots of resources - I'll try again
Grahame Grieve (Dec 16 2021 at 18:01):
so, I have redone the analysis, and considered a number of issues with packages. Details on that in the #tooling stream
Grahame Grieve (Dec 16 2021 at 19:00):
this is correct as far as I can tell:
Grahame Grieve (Dec 16 2021 at 19:00):
-- v1.0---------------------
distance n/a nearby normal phonetic
reference 0 / 0 0 / 0 0 / 0 284 / 0 0 / 0
date 0 / 0 0 / 0 0 / 0 81 / 0 0 / 0
number 0 / 0 0 / 0 0 / 0 6 / 0 0 / 0
quantity 0 / 0 0 / 0 0 / 0 4 / 0 0 / 0
string 0 / 0 2 / 0 0 / 0 117 / 0 4 / 0
composite 0 / 0 8 / 0 0 / 0 0 / 0 0 / 0
uri 0 / 0 0 / 0 0 / 0 33 / 0 0 / 0
token 1 / 0 1 / 0 1 / 0 363 / 2 0 / 0
-- v3.0---------------------
distance n/a nearby normal phonetic
reference 0 / 0 0 / 3 0 / 0 425 / 5 0 / 0
date 0 / 0 0 / 0 0 / 0 112 / 2 0 / 0
number 0 / 0 0 / 0 0 / 0 9 / 0 0 / 0
quantity 1 / 0 0 / 0 0 / 0 9 / 0 0 / 0
string 0 / 0 0 / 0 0 / 0 163 / 2 2 / 0
composite 0 / 0 0 / 0 0 / 0 12 / 1 0 / 0
uri 0 / 0 0 / 0 0 / 0 47 / 0 0 / 0
token 0 / 0 0 / 0 1 / 0 464 / 6 0 / 0
-- v4.0---------------------
n/a nearby normal phonetic
reference 0 / 32 0 / 0 476 / 41 0 / 0
date 0 / 6 0 / 0 113 / 18 0 / 0
special 1 / 0 1 / 0 0 / 0 0 / 0
number 0 / 0 0 / 0 7 / 0 0 / 0
quantity 0 / 0 0 / 0 27 / 0 0 / 0
string 0 / 16 0 / 0 139 / 12 3 / 0
composite 0 / 0 0 / 0 46 / 0 0 / 0
uri 0 / 0 0 / 0 45 / 0 0 / 0
token 0 / 25 0 / 0 542 / 53 0 / 0
Grahame Grieve (Dec 16 2021 at 19:03):
distance appears to be a candidate for being toasted
Grahame Grieve (Dec 16 2021 at 19:06):
as does other? But I thought we used that for _filter and similar. Turns out that they don't have a stated value for usage... so maybe we should toast other?
Lloyd McKenzie (Dec 16 2021 at 19:39):
I think 'other' is still relevant - the element is required if expression is present, which means if it's not "normal" or "phonetic", you need to specify something. "other" essentially says "custom code it". Alternative is to remove the invariant, but then people might forget to populate it when 'normal' or 'phonetic' apply.
Brian Postlethwaite (Feb 03 2022 at 06:34):
For this one, I'd be happy with phonetic and special only (and normal usage is just missing altogether) where special means hard coding, which nearby/distance are. And phonetic kinda fits that, buts it's general enough that no real problem to implement.
+1 to rename.
Grahame Grieve (Feb 03 2022 at 21:08):
@Yunwei Wang I think it's time to put this back on FHIR-I agenda
Lloyd McKenzie (Feb 08 2022 at 00:12):
Created FHIR#35974 based on follow-up discussion
Last updated: Apr 12 2022 at 19:14 UTC
