Stream: conformance
Topic: Forge feature request
Grahame Grieve (Jul 12 2017 at 10:27):
@Michel Rutten using Forge is really slow and frustrating. Actually, no, profiling is really slow and frustrating. Forge kind of magnifies it a little because it is slow to move from element to element. but what would really save me a lot of time is to be able to right click on an element, and turn all it's children off - set cardinality to 0..0 for anything that doesn't have min = 1
Grahame Grieve (Jul 12 2017 at 10:29):
another thing that would be just sensational - though there are many difficulties - is to copy/paste stuff. I have a set of constraints on .subject that is the same in all my profiles...
Ewout Kramer (Jul 12 2017 at 10:45):
@Michel Rutten using Forge is really slow and frustrating. Actually, no, profiling is really slow and frustrating. Forge kind of magnifies it a little because it is slow to move from element to element. but what would really save me a lot of time is to be able to right click on an element, and turn all it's children off - set cardinality to 0..0 for anything that doesn't have min = 1
I think I heard @Michel Rutten mention copy & paste once......yes that would be really useful!
Grahame Grieve (Jul 12 2017 at 10:46):
Also, on References, this sequence keeps catching me out:
- I set cardinality for children to 0..0
- then I set .reference to 1..1 and update it's documentation to what I want
- then I remember to uncheck all the possible target profiles on the Reference itself, and check the one that applies
- and now I have lost anything I applied to the chidlren
Michel Rutten (Jul 12 2017 at 13:52):
Hi @Grahame Grieve, thank you for your feedback!
We could certainly implement a (context menu) command to strike all child elements of the selected node. Never thought about it before, but I see how this would be useful.
Regarding element navigation, maybe we could implement some handy keyboard shortcuts to traverse the element tree. Would that be helpful?
Copy/paste would be really convenient, but unfortunately this is not so easy to implement, as it involves dynamically merging complex (sub)trees and dealing with discrepancies. I'd love to provide such a feature, but realistically, I don't expect this to happen soon. For now, our main priority is to correctly handle the advanced use cases, as we see an increasing complexity in profiles that users try to create.
Michel Rutten (Jul 12 2017 at 13:59):
As for constraining references, if you change the datatype of a (polymorphic) element, Forge will try to re-expands all child elements. This allows you to author complex (deep) constraints on e.g. valueCodeableConcept. However it also implies that when you modify the datatype of an element, you inevitably loose all the existing child constraints. I'm open for suggestions on how to improve this.
The problem somewhat resembles copy/paste, as an ideal solution would involve merging complex subtrees and gracefully dealing with discrepancies (i.e. trying to maintain all compatible constraints after changing the datatype). Currently, Forge doesn't even try to perform a merge, but simply discards all existing child constraints.
Grahame Grieve (Jul 12 2017 at 20:33):
I follow the logic of why changing the type resets the elements. But right now, changing the targetProfile resets them. That's the bit I don't appreciate. Changes to targetProfile should not change the child eleements
Michel Rutten (Jul 13 2017 at 09:03):
Forge tries to apply/merge target profiles on the fly, in order to show the inherited constraints from the external profile so the author can then further constrain the elements. Anyway, that is the intent.
Michel Rutten (Jul 13 2017 at 09:04):
e.g. an external target profile might introduce slices and/or extensions that you'd like to see inlined in the tree.
Grahame Grieve (Jul 13 2017 at 14:48):
I don't follow how that would happen at all. not for targetProfile. Of course that would be on for the profile element
Michel Rutten (Jul 13 2017 at 14:56):
I think your're right... This looks like a symptom from DSTU2 => STU3 migration. I'll revisit the event logic, seems like I should disable child re-expansion for .targetProfile.
Michel Rutten (Jul 18 2017 at 08:27):
@Grahame Grieve FYI I've improved the logic responsible for expanding element type profiles. Forge now only performs (re-)expansion when necessary, i.e. when the (common) element type and/or profile has changed. Changes to the .targetProfile property no longer trigger re-expansion.
The improvement will be included in the upcoming new release.
Michel Rutten (Jul 18 2017 at 13:24):
Hi @Grahame Grieve, you suggested the following feature request:
"but what would really save me a lot of time is to be able to right click on an element, and turn all it's children off - set cardinality to 0..0 for anything that doesn't have min = 1"
Could you explain use case(s) when such a command would be useful? Would you mostly use this to profile e.g. ResourceReferences?
Trying to determine if/how useful this would in general.
Grahame Grieve (Jul 21 2017 at 12:18):
thanks for the logic improvement
Grahame Grieve (Jul 21 2017 at 12:19):
when I'm profiling resources for actual implementations, I find that there's a lot of labor involved. One common operation I do is turn everything 'off' and then bring back what I'm going to use. I've found that I've missed things by getting distracted by the logic of what I'm doing.
Grahame Grieve (Jul 21 2017 at 12:20):
this is particularly relevant in resource structures, where there can be quite a lot of children...
Grahame Grieve (Jul 21 2017 at 12:20):
I'm trying to find ways to reduce the laboriousness of profiling
Michel Rutten (Jul 24 2017 at 09:45):
That makes perfect sense, thank you for the motivation. I've added a ticket for your feature suggestion.
If you have any other ideas on how to improve the profiling workflow, please let me know.
Grahame Grieve (Jul 25 2017 at 08:09):
sure. I'll keep letting you know.
Grahame Grieve (Jul 25 2017 at 08:09):
the next really useful feature will be to generate a profile from an instance
Grahame Grieve (Jul 25 2017 at 08:10):
I think that will be like the code generation stuff I did - something to package on my server so you could call it there
Michel Rutten (Jul 25 2017 at 08:12):
Hi @Grahame Grieve, thanks for the feedback. Definitely an interesting feature suggestion. But it sounds like quite a hairy problem to solve... how would the logic deal with ambiguities and/or options?
Grahame Grieve (Jul 25 2017 at 08:13):
well, you can only get close. Then the user has to load the profile into forge and fix up all that stuff.
Grahame Grieve (Jul 25 2017 at 08:13):
that's why it's a forge feature - it's a way to get a leg up on the work, not an actual solution
Michel Rutten (Jul 25 2017 at 08:45):
Got it. Would certainly be useful. I've created a new ticket for your feature suggestion. Thanks!
Last updated: Apr 12 2022 at 19:14 UTC
