Stream: implementers
Topic: StrucDef.url and base
Alexander Henket (Mar 17 2017 at 13:27):
Looking at http://hl7.org/fhir/visionprescription.profile.xml.html:
.
Today for DSTU2 it has canonical URL "http://hl7.org/fhir/StructureDefinition/VisionPrescription" and base "http://hl7.org/fhir/StructureDefinition/DomainResource"
.
This doesn't tell me anything about what version of FHIR we are dealing with. I could look at .fhirVersion ("1.9.0"), but my resolving is hard that way.
.
Would it make sense to assume a strategy where canonicals and baseDefinition include the right permalink? E.g.
.
<url value="http://hl7.org/fhir/DSTU2/StructureDefinition/VisionPrescription"/>
<baseDefinition value="http://hl7.org/fhir/DSTU2/StructureDefinition/DomainResource"/>
.
The same logic would apply to extensions. This way in 2/3 weeks time when STU3 is done I could get a distinct new version of the profile.
Grahame Grieve (Mar 17 2017 at 13:35):
STU3 is a few days away
Grahame Grieve (Mar 17 2017 at 13:35):
not a few weeks
Alexander Henket (Mar 17 2017 at 14:52):
Ok. Doesn't change the question though. Even if it's not going to change what comes out of STU3. We could still look into what to do for STU3 Patch 1 or R4. I have a feeling there's something to solve here, but I'm currently just checking if my hunch is right.
.
For reference: this question came from a rather lengthy/ferocious discussion over at the Netherlands stream. We have a 'big' number of DSTU2 profiles that we will need to convert to STU3 and we are wondering what to do with the canonicals and extension URLs in that conversion.
.
I cannot leave them as is and publish the new versions on Simplifier. I'm afraid it would be a disaster to distinguish what's what. I'm not sure whether to update them when I see that the FHIR Core materials don't. But I mostly wonder whether it is correct that the FHIR Core doesn't update them and how the resolving of artifacts works then.
.
Hence the question.
Grahame Grieve (Mar 17 2017 at 19:34):
I don't know what the answer is. I agree that there's a problem to think about. If you look at the R2 structure definitions included in R3, they have the urls you are talking about - I made that change. But doing that broken so many things - both practically and conceptually
Alexander Henket (Mar 18 2017 at 07:24):
I'm not sure how to spot R2 profiles in between R3, but I'll take your word for it. If there indeed is a problem then I'm sure for example @James Agnew must have run into that when he built the R2 > R3 conversion, or @Richard Ettema must have seen it when he gathers stuff for validation. That's the practical side. What would you say is a/the conceptual problem?
.
I remember a discussion on ValueSet.url for expansions where we landed on the ValueSet.url being a logical identifier rather than an instance type identifier, so that meant that ValueSet.url for intention and expansion can in fact be the same because the logical intention is the same. Supposedly you could look at StructureDefinition.url the same way.
.
I'm not sure about StructureDefinition.id and .baseDefinition. If the .id and .baseDefinition point to objects that can change structure overnight (R2 > R3) then I'm not sure what breaks when overnight happens. Same with extension.url. If my instance claims conformance to a profile on R3, I'd expect every extension to be R3 too. But a given extension may not be part of the (open) R3 profile and only exist in R2 space. Can I reject instances based on mixed versions of definitions?
.
Seems to me that after R3 is out we will get real world feedback on this. Versioning has been V3s weakest point with every Normative Edition being compatible with itself, so I'd love to help avoiding that in FHIR.
Grahame Grieve (Mar 18 2017 at 11:11):
I wrote the R2 <--> R3 conversion, so it's me that had the issue. Somewhere, I hack(ed) the URLs. can't remember whether it's as I load, or manually now
Grahame Grieve (Mar 18 2017 at 11:14):
what I've learnt about versioning is that choices I make seem real clear to me, but they aren't clear to everyone else. And they won't remain clear to me either. and everyone is the in the same boat.
Grahame Grieve (Mar 18 2017 at 11:14):
so I think that we should gather feedback and see
Grahame Grieve (Mar 18 2017 at 11:15):
I do it while loading the R2 definitions into R3:
if (patchUrls) {
for (BundleEntryComponent be : b.getEntry()) {
if (be.hasResource() && be.getResource() instanceof StructureDefinition) {
StructureDefinition sd = (StructureDefinition) be.getResource();
sd.setUrl(sd.getUrl().replace("http://hl7.org/fhir/", "http://hl7.org/fhir/DSTU2/"));
sd.addExtension().setUrl("http://hl7.org/fhir/StructureDefinition/elementdefinition-namespace").setValue(new UriType("http://hl7.org/fhir"));
}
}
}
Alexander Henket (Mar 18 2017 at 11:19):
Right, so there is some hacking involved for resolving. I'll leave you to finalizing R3 as I'm sure you'll need your time. Let's revisit this with wider implementer input. If that input doesn't come, then it may not be a big enough issue.
Marten Smits (Mar 20 2017 at 12:12):
For Simplifier we will definetely run into issues here. Since we currently have uploaded the DSTU2 definitions. When the R3 definitions have the same canonical URL (which they currently have), we will have to do some hacking to make multiversioning happen. It would have our preference that the canonical URL of the resource will change with its FHIR version (since there are a lot of breaking changes).
Marten Smits (Mar 20 2017 at 12:19):
@Grahame Grieve I know this is really late, however would it be an idea to change the base from http://hl7.org/fhir/ to http://hl7.org/fhir/STU3/in the url of the resource definitions, as you did with DSTU2 above?
Marc de Graauw (Mar 20 2017 at 14:11):
There are several pieces on the internet advocating versioning by media type instead of url. Something like: application/fhir+json.stu3 and application/fhir+json.dstu2 would retrieve the appropriate resources from the canonical url. And application/fhir+json would get either the first or the last. See for instance https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/ or others. Not sure whether I like this approach, but it is a option to keep url's stable while still having versioning. The main idea is 'the url's identify the resources, not the version of the resources" - which in itself is a reasonable idea.
Oops, same link I posted was already in another thread yesterday which I didn't follow well enough, apologies.
Lloyd McKenzie (Mar 20 2017 at 14:47):
-1 on changing the cannonical URL. I'm not a huge fan of changing the URL either. Once we're in normative, neither should matter and it would be good to have implementers get used to that and rely on context (what endpoint is hit, etc.) to differentiate until then. We should however be changing the business version. Cannonical URL + business version should get you to an official release.
Last updated: Apr 12 2022 at 19:14 UTC
