Not sure I understand this bit - the two alternative constraints have distinct paths:
.../value[id4]
.../value[id5]
You might be thinking in ADL1.4 terms, but in AOM2, every node has an id-code (it’s just that not all id-codes have terminology definitions). So in the final data you can always tell which node the instance data conformed to. Indeed, you could have a DV_CODED_TEXT in the data containing a term that doesn’t match the id4 constraint, and it would still be allowed to match the id5 constraint, since a DV_TEXT constraint node means ‘a DV_TEXT instance, or an instance of any RM sub-type is ok here’. Which is exactly the thing we are trying to prevent, which is why we need to do something special. So for now, I am proposing only additions to the AOM, nothing on the RM.
Ok, I see what you mean now. I think my point re the misuse of [id5] still stands though, and it is not easy to enable that misuse either, unless you’re using some sort of form generator approach that automatically allows a UI widget etc to offer dv_coded_text based input for every dv_text node in the archetype.
I (currently) think, if we are to disallow this, some AOM level annotation approach would be the cleanest option, after having this discussion, but I’m very reluctant to make use of that anywhere but validation. Implementers can choose to do whatever they want of course, but there be dragons…
Anyway, this is all I can contribute today, hopefully I’ll go over this again, if the above comments don’t make sense, just ignore them on account of being made with less attention than the issue deserves.
Ah but that is the key issue. In the UK allergies context I want to enforce the use of agreed terminologies but I also have t to accept that there are cases where only free text can be used (foreign drugs, experimental drugs). What I don’t want to be used is any other kind of terminology. It’s either use our agreed terminology constraints or free text - no other terminologies allowed.
and I’m happy with the AOM suggestion.
There is possibly some additional value beyond just the terminology issue. There are a few places where being able to prevent the use of codes in a DV_TEXT constraint i.e prevent sub-classing to DV_CODED_TEXT, would be valuable e.g where the purpose of the element is to carry pure narrative.
I’m being very rude, I know, but how about telling the software implementer not to allow coded entry to dv_text field and let validation take care of your terminology constraint for the other field?
It is not like models are thrown into a magic room where software comes from another room. these things are not meant to be and never turned into software fully automatically. I wish they could, we’d then all find new jobs and have normal lives…
You are being rude but in this case ‘English rude’ but not ‘Turkish/Scottish rude’ , which is a whole other thing
In the context of a single developer environment you are probably correct but it a world where we are trying establish the rules for a wide range of different downstream suppliers, the less we have to depend on written guidance, the better.
We definitely need to get @borut.fabjan into the discussion as this was a real concern for him which he raised in Braunschweig.
So I think my rm_type_final proposal, or something close to it, will do what you want, even in circumstances other than the DV_CODED_TEXT + DV_TEXT situation.
Well sometimes you do want to allow this - maybe with other RM types like PARTY_PROXY and subtypes, or classes in another RM entirely. We need to be able to signal either design intention to the tools.
@thomas.beale proposal above seems to me a good one, and it might avoid introducing a new class as a patch (for the problem), and like @Seref mentioned, is a cleaner solution to the real problem.
The not-yet-quite-expert-panelist @borut.fabjan does not seem to have access to this category. Could somebody grant that access to him? Does it matter whether he somewhat-formally agrees to his status of an expert?
For us the closed/rm_type_final part would be much easier to implement than a new data type - just add the changes in the AOM and the grammar, add two archetype validations and an RM object validation and this is fully supported. DV_PLAIN_TEXT would require changes to be made in any app that could potentially encounter the data type.
If any apps exist that allow for a DV_TEXT to be replaced with a DV_CODED_TEXT at data entry time, so without template or specialisation, that will require work - but those require work for a DV_PLAIN_TEXT type as well.
However, I still fail to see that this solves a real problem, and not just a theoretical one.
We could also add a warning to the archetype validation if someone tries to specialise a DV_TEXT in a DV_CODED_TEXT in the specific case that another DV_CODED_TEXT alternative is already available, explaining why doing this is generally a bad idea and why any recorded data will fail to validate against the parent archetype.
I did also think of this, and indeed, we could go as far as stating it as a rule. It seems sensible but I suppose someone might eventually come up with a reason why it should not apply in some other circumstances…
(here you go discourse. the post is not empty anymore happy? longer than 10 chars as well. never mind the above quotes you idiotic piece of code, force me to type this insisting the post can’t be empty…)
It would be good to get @borut.fabjan views as he was te one who raised the technical/philsophical concern. A closed flag is fine for me.
I don’t think it is a completely obscure or purely theoretical use-case. Possibly not a single company level but when developing cross-org standards being precise like this as per my allergies example, is something that experienced informaticians get angsty about!!
I’m not too bothered about the warnings - that feels like a fair amount of work. As long as I can capture the requirements correctly and pass them on, that’s enough for me.
Archetype validators generally already have the ability to add warnings, and generally have all the necessary data available in its validators already, and tools can usually already show warnings. That means adding a warning is very little work, modelling tools do not need new features in their user interface, and modellers do not need to learn new concepts. It is less work than adding a feature to the AOM/ADL. I would say a new data type is even more work than that, but others might disagree.
I think the choice of solution depends on a couple of things. If we use need a solution for this one single use case, adding a warning could be very well a very simple and effective solution. You do not have to do anything different when modelling - just when people try to specialise a DV_TEXT when there is already a different DV_CODED_TEXT they will automatically be warned that this usually is a bad idea unless you know exactly what you are doing, and if it could show these warnings in the CKM governance could be easy as well.
If we need a closed/final keyword for more use cases, and/or if this really needs to be enforced and a warning is not enough, then that could be a better solution.
I personally do not really like the idea of a new data type just for this purpose. I think it makes things more complicated to understand.
I guess I am seeing this more through the lens of regional/national standards development where the downstream consumers of the archetypes and templates or other derived artefacts/documentation will probably not be using archetype tooling. If I cannot capture ‘nosubclassing’ as part of the computable definition, I am reliant on implementation guidance.
Could you explain what you mean with not using archetype tooling? How are they going to specialise a DV_TEXT without using archetype tooling, especially when using ADL 2?
You mean that application code could break the original design intention by supplying a DV_CODED_TEXT for the DV_TEXT field - but to stop that being saved, we’d have to have the archetype constraint check prevent it. Which means that we are talking about more than a design-time tool warning…
That would not be solved using the aom/ADL changes. That means changes to the validation logic. I wonder how many frameworks or cdrs consider that subclassing to be correct - I’m not even sure what Archie does here.
It is also not specific at all to adl2 - what was suggested in the first few posts.
