Stream: terminology
Topic: ValueSet versions in $validate-code
Jack Bowie (Feb 23 2018 at 00:27):
Hi guys! Am I correct that the /ValueSet/$validate-code/... form does not support a specific version of the ValueSet target?
Grahame Grieve (Feb 23 2018 at 01:02):
how are you identifying the value set?
Peter Jordan (Feb 23 2018 at 01:06):
The 'version' input parameter to the ValueSet $validate-code operation relates to the version of the Code System, so I'd say you are correct unless the version of the Value Set is implicit in a requested id or url, or you supply the valueset itself in the request.
Grahame Grieve (Feb 23 2018 at 01:16):
right. you can either:
- execute $validate code on a particular value set - that is the right version (well, hopefully)
- provide a canonical URL - which can contain a version if you want
- provide an actual value set ( which will also hopefully be the version you want)
Rob Hausam (Feb 23 2018 at 01:18):
yes, Carol Macumber and I were just talking about this, and Carol is planning to submit a tracker for adding a value set version parameter for $validate-code
Grahame Grieve (Feb 23 2018 at 01:24):
when would you use it?
Rob Hausam (Feb 23 2018 at 01:30):
I didn't have a chance to discuss the details of that with Carol, but I expect she will put it in the tracker
Grahame Grieve (Feb 23 2018 at 01:34):
ok. I just don't think there's a chance to use it
Rob Hausam (Feb 23 2018 at 01:41):
the similar discussion on the Vocab call was about adding the value set version parameter for $expand (approved GF#13820), which there does seem to be interest in
Peter Jordan (Feb 23 2018 at 02:32):
Now (R4) that there is a $validate-code operation for the Code System resource - that also has the Code System version as an input parameter, I'm wondering whether this might be a case of re-scoping the version input parameter for ValueSet$validate-code to apply to the value set version. Is there still a use case for using a ValueSet operation to determine if a code belongs to a particular version of a CodeSystem?
Jack Bowie (Feb 23 2018 at 17:57):
Re Graham's comment that the URL could contain a version, this is very difficult for us. Versions are subsidiary objects to our "base" ValueSet (Subset) object . I do not believe we should conflate url and business version semantics.
Grahame Grieve (Feb 23 2018 at 18:38):
see http://build.fhir.org/references.html#canonical
Rob Hausam (Feb 23 2018 at 19:32):
I think it's still somewhat unclear where you can and can't use this (and which servers, if any, support it). This is on $expand, rather than $validate-code, but should I be able to do this?
Peter Jordan (Feb 23 2018 at 20:47):
@Rob Hausam my reading of the spec is that a server should be able to resolve that URL, but it is not mandatory to do so. Given the likelihood of varying implementations, and the possibility that some value set authors will have policies that prevent them appending versions to urls, my view is that it's safer to rely on the version property of the value set. However, it might still be a good idea to test that syntax in Cologne which would mean preserving the C17 versions of the test value sets and adding C18 versions @Richard Ettema
Rob Hausam (Feb 23 2018 at 21:12):
yes, I agree with all of that
Grahame Grieve (Feb 23 2018 at 21:54):
"the possibility that some value set authors will have policies that prevent them appending versions to urls" - since that's an API thing, we would there be a policy?
Peter Jordan (Feb 23 2018 at 23:48):
The initial post in this thread expresses some discomfort with conflating 'url and business version semantics', I also heard differing views on this topic at the last WGM. Not quite sure what you mean by an 'API thing' - some might interpret that as an implementation concern, rather than something mandated by the spec (which it doesn't appear to be anyway...at this point in time).
Grahame Grieve (Feb 23 2018 at 23:52):
the spec is about the API, and it mandates the API
Rob Hausam (Feb 24 2018 at 01:49):
In the context of this discussion, which aspect(s) of the API specifically are you saying that the spec is mandating? Because that still doesn't seem to be coming across clearly in the same way to everyone.
Peter Jordan (Feb 24 2018 at 01:52):
The spec states "When the type of the canonical reference is a uri, the URL may include a version, in order be precise about which version of the resource is being referred to." and "Servers SHOULD support version specific searching for canonical URLs by automatically detecting the presence of a |[version] and performing the appropriate search." I read that as recommended rather than mandatory behaviour and will check for a version parameter before attempting to fish the version out of a URL.
Rob Hausam (Feb 24 2018 at 01:55):
I would read that the same way. And so far I'm not seeing that existing servers (including Grahame's) are supporting the appending of a version to a canonical uri/url, except possibly in some very selective cases.
Grahame Grieve (Feb 24 2018 at 07:12):
ok fine. the documentation could be clearer. But that's not grounds for deciding one way or the other. I don't think that there's any reason for us to allow version done both ways - it should be only done one way
Michael Lawley (Feb 24 2018 at 07:41):
I always have great discomfort about 3rd party manipulation of URIs. These are "owned" by the issuing party, not by the FHIR spec, and it is possible that some 3rd party meaning/significance might be attached to a URI ending in |[version] that's entirely different to this FHIR spec meaning. I am much more in favour of a separate version parameter unless there is a compelling reason to be able to pack it in to a single reference.
(and can we be consistent about calling them URIs not URLs; I know its anal, but being clear an consistent helps those who don't fully appreciate the difference)
Rob Hausam (Feb 24 2018 at 11:34):
@Grahame Grieve @Michael Lawley I agree that we should do it one way. Which way is that? Are we going to follow Michael's (and other's) suggestion and use separate version parameters? And therefore remove the appending of |[version] to canonical uris from the spec. And would we change the 'url' elements on resources to 'uri' - a breaking change on conformance resources?
Grahame Grieve (Feb 24 2018 at 19:24):
those are different issues
Peter Jordan (Feb 24 2018 at 20:17):
+1 for using separate version parameters. Agnostic on the other issues in Rob's last post.
Rob Hausam (Feb 24 2018 at 20:54):
I agree that changing 'url' to 'uri' is a separate issue, and can be decided separately.
Grahame Grieve (Feb 24 2018 at 20:58):
actually, if we changed it, it would from url to canonical
Rob Hausam (Feb 24 2018 at 22:05):
Sure. I thought I recalled someone expressing a preference for using 'uri' rather than 'canonical' for the element name, but I'm not finding that now. I think I'm fine with either one.
Michael Lawley (Feb 25 2018 at 05:21):
I didn't meant to raise the renaming again, it was actually a plea for people to be consistent in their usage on Zulip and elsewhere when writing about these things :)
Grahame Grieve (Feb 25 2018 at 10:50):
queue the sound of hollow laughter...
Rob Hausam (Feb 25 2018 at 13:17):
@Michael Lawley I don't know that you did raise the naming issue again - it wasn't your "consistent about calling them URIs not URLs" comment that I was thinking of. But, no matter. It seems that we've settled on 'canonical'.
Lloyd McKenzie (Feb 25 2018 at 20:23):
I don't think we've settled on renaming the attribute... My understanding is that ValueSet.url, StructureDefinition.url, etc. will continue to have the same name.
Grahame Grieve (Feb 25 2018 at 23:03):
have to make final decision tomorrow on that
Rob Hausam (Feb 26 2018 at 14:03):
Presumably we'll be discussing and deciding this on FHIR-I, then? If we can do it in the first hour, that would be good, as it overlaps with Vocab FHIR Tracker Issues in the 2nd hour. If the FHIR-I calls are usually going to be 2 hours we may need to consider adjusting the Tracker Issues call time.
Robert McClure (Feb 26 2018 at 17:51):
@Grahame Grieve and @Rob Hausam I'm completely confused as to why you all don't think version-specific value set API access in general is something everyone will need.
I must be missing something critical. I see this as something that we always need and my (perhaps incorrect) understanding is that the only way to do operations on a version-specific value set is to know the server-specific ID. @Carol Macumber
@Peter Jordan If we have no other choice then to change "version" to mean value set versus code system, I'd agree to do that. I certainly hope that all validates value set operations are against the expansion and to get an expansion you must be able to specify a value set version, a code system version or an expansion profile. We've laid out the precedence of how to work through dates and versions of things in the binding project. See "Deterministic Expansion identified by a binding with precedence as determined below (as of 2/20/18):" at http://confluence.hl7.org:8090/display/VOC/Vocabulary+Binding+Semantics+%28VBS%29+Project
Grahame Grieve (Feb 26 2018 at 17:54):
you'd be confused because we don't think that. We're just discussing how it's done. It's not the only way to do it
Robert McClure (Feb 26 2018 at 18:02):
Ya - I had not read all the rest of the thread. Now catching up... Doesn't this overlap with the general discussions that @Ewout Kramer has been involved with on resource versioning? I'm really struggling to keep all this clear...
Grahame Grieve (Feb 26 2018 at 18:16):
sort of overlaps, yes. but the discussion is pretty specific: we know that we need version specific references, and what the version refers to. We're just discussing exactly where it does when invoking $expand and $validate-code
Last updated: Apr 12 2022 at 19:14 UTC
