Stream: conformance
Topic: expanded context on an extension
Eric Haas (Jun 13 2018 at 20:51):
When I have a new context for an existing extension, I create new extension instead of profiling the old one( we are talking IGs here) , because I don't see any benefit. It is just as much work all around to support a new extension vs profiling an old one. Is there an easier way?
Lloyd McKenzie (Jun 13 2018 at 20:55):
If you can profile an existing extension, that's always better. The reason is that systems are going to choose to implement specific extensions by URL. If you profile the existing extension, any system that recognizes that URL will know what it means and be able to map it, display it, etc. If you create your own custom extension, no one will know what it is - which sort of defeats the purpose of sharing it. Creating a custom extension to constrain is as much a problem as creating a custom extension rather than using a core element. If you can re-use & profile, that's almost always a better path.
Eric Haas (Jun 13 2018 at 21:39):
The profile gets its own url just like the new extension so I am not sure anything is gained. What do you mean by "That URL" in ' if you profile the existing extension, any system that recognizes that URL will know what it means and be able to map it, display it, etc.'?
Grahame Grieve (Jun 13 2018 at 21:48):
This is an interesting question. What's case for 'profiling an extension'? We've never really talked about this to my knowledge
Eric Haas (Jun 13 2018 at 23:09):
adding context A to extension B. I've actually never done it, but I presumed it was possible.
Grahame Grieve (Jun 13 2018 at 23:23):
I don't think it is. It can't be added to the source of the extension?
Lloyd McKenzie (Jun 14 2018 at 00:44):
The profile has a URL, but it doesn't change the fixed url.value of the original profile
Lloyd McKenzie (Jun 14 2018 at 00:44):
So the profile URL is new, but the extension URL remains the same.
Lloyd McKenzie (Jun 14 2018 at 00:45):
I've profiled quite a few extensions for my IGs - some HL7 defined and some defined within the IG itself where I had re-useable constraints that were different for the same base semantic.
Lloyd McKenzie (Jun 14 2018 at 00:45):
It works just fine with both the validator and the publisher.
Lloyd McKenzie (Jun 14 2018 at 00:46):
It just requires a bit of training for people to get used to the fact that "URL used to reference the extension in the spec is not necessarily the same as the URL of the extension".
Grahame Grieve (Jun 14 2018 at 00:52):
I dislike this complexity
Lloyd McKenzie (Jun 14 2018 at 01:09):
There's no complexity. It's just how profiling works.
Lloyd McKenzie (Jun 14 2018 at 01:09):
And there are use-cases where it's necessary.
Lloyd McKenzie (Jun 14 2018 at 01:09):
We're not introducing any magic here.
Grahame Grieve (Jun 14 2018 at 01:16):
no, on reflection, I think I have a problem with this.
Grahame Grieve (Jun 14 2018 at 01:16):
I have an extension A. It's allowed to be used at elements X and Y
Grahame Grieve (Jun 14 2018 at 01:16):
you can't, somewhere else, in a 'constraint' assert that hey, we can use it on Z too
Lloyd McKenzie (Jun 14 2018 at 01:20):
Agree with that
Lloyd McKenzie (Jun 14 2018 at 01:20):
You can't change the allowed applicability
Lloyd McKenzie (Jun 14 2018 at 01:21):
But you can constrain the data type for the value or child components and/or provide additional contextual guidance on their use.
Lloyd McKenzie (Jun 14 2018 at 01:22):
In theory I guess you might be able to say that your constrained version is only allowed to be used at element X and not Y - that would be a legal constraint. Though I haven't ever had a use-case to do that and can't, off the top of my head, think of a situation where an extension profile would need to do that.
Ewout Kramer (Jul 02 2018 at 09:54):
It just requires a bit of training for people to get used to the fact that "URL used to reference the extension in the spec is not necessarily the same as the URL of the extension".
I never considered this, interesting. But since the instance will refer to the old url, the only way to enforce the additional constraints in the profiled extension is by having an instance refer to a profile that points to that profiled extension?
Grahame Grieve (Jul 02 2018 at 10:12):
yes
Lloyd McKenzie (Jul 02 2018 at 10:55):
Yup
Lloyd McKenzie (Jul 02 2018 at 10:55):
Which is exactly what the implementations I have that do this do.
Last updated: Apr 12 2022 at 19:14 UTC
