Hello everyone,
I am currently facing the following problem:
I have a document model to represent a single entity (let’s call it DomainSingleEntity).
The model tree is not particularly complex. A group (Name = SingleEntity, Repetitions = 1) containing various fields (strings, enumerations, numbers, booleans). The internal description of the “SingleEntity” group is important for the dependent functionalities of our application. Here we maintain a text for a specific language. The internal description is then also the central point of my problem.
Because we maintain another document model (let’s just call it DomainSingleEntityList). It lists the previously described SingleEntities. Not more. The model tree is correspondingly simple. A Group “SingleEntityList” contains an Include (which we call “SingleEntityInclude” here). We use this to include the document model DomainSingleEntity with a repetition of 99999.
If I now collapse the include SingleEntityInclude in the SME, I see the following: All fields that are arranged in the document model DomainSingleEntity under the group SingleEntity are directly under the Include “SingleEntityInclude”. But not the “SingleEntity” group from DomainSingleEntity itself… Reading in the corresponding documents in the Java code is similar. The Include “SingleEntityInclude” becomes a GroupInstance - but the group “SingleEntity” from the document model DomainSingleEntity with our important internal description seems to be missing.
To me this feels like a bug. If so, is there already a fix for this (we use A12-2022.06 / Dataservice 34.2.3 and kernel 27.3.2)? Or is there a workaround?
Hi Mathias,
as far as I understand it, this is considered the correct behaviour by A12. Only the children of the root group will be carried over to the including model, see: Preserving annotations in includes I guess an argument could be made to change this behaviour but currently this appears to be the way it works.
Hi mhansemann,
thanks for your reply. That actually seems to answer my question. Only the children of the root group will be carried over to the including model. This also explains why only one group is allowed for the included model at the top level. Otherwise the SME reports that (The included model may only contain a single, non-repeatable group at top level). So my internal description is simply discarded like the repeatability or the annotations and only the elements of the original group are copied under the new “include group”?
So how should I deal with this? In the including model, hang the include under a new group that is the exact copy of the top-level group of my model to be embedded? So I have to maintain the values twice? In the end I just want my fields in both models (included and not included) to be under the same Group with the same Internal Description.
Do you have any advice on how to deal with this requirement?
Hi @mathias-early-ravine,
could you please explain why the internal description is important for the dependent functionalities of your application? Do you take it to show it to the end-user? Or what do you do with that?
The internal description of any element in the document model is meant to be a documentation for the modelers. In case of inludes: The description of the root group to be included would describe the abstract case (e.g. address) and the description of the including group would be the special case (e.g. shipping address), that’s why I don’t understand yet, why you would like to transfer the internal description.
@gildardo-cached-canyon
We are (mis)using “internal description” for a transformation process, which transform a12-documents into another structure (which is then fed into an external system). We’ve been using this for a long time (since 2018). We had to use a “language/locale” approach - and not annotations -, as we also have to transform enumeration values (and there are no annotations for enumeration values).
We might not even need the transfer of the “internal description” of the include to the including model. What would solve our problem - without breaking the existing process - would be the ability to set an “internal description” on the include (or rather its root group) in the including model. Currently, this does not seem to be possible (there is not “internal description” section on the include in the SME). I guess this would be a valid addition (for the sake of consistency alone).
For the time being we’ve worked out a solution using annotations for this specific case and adjusted our transformation mechanism.
@anon67142020: Thanks for the explanation. I was not aware that includes are not treated as groups in the SME, even Kernel does it. From my point of view, it is a valid requirement to set an internal description for an include. Would you create a corresponding A12 requirement?
@gmorga-ramirez
Thanks for your answer.
I would create a requirement, but do not have access to mgm’s Jira.
I just created a requirement. Even you don’t have access to mgm’s JIRA, this is the ticket number A12-14719.