search

DATEX-II-EU / DatexII

Main repository for issues and bugs for the DATEXII standard
0 stars 0 forks source link

Should we prevent identically named classes in the same inheritance tree? (Bugzilla Bug 479) #479

Closed datexii closed 3 months ago

datexii commented 8 months ago

This issue was created automatically with bugzilla2github.py

Bugzilla Bug 479

Date: 2024-03-21T11:48:30+01:00 From: @iancornwellmottmac To: @JosefKaltwasser

Last updated: 2024-03-22T12:12:35+01:00

datexii commented 8 months ago

Comment 1928

Date: 2024-03-21 11:48:30 +0100 From: @iancornwellmottmac

Bugzilla #251 shows the problems encountered as a result of our design of having a class with a base class of the same name from another namespace. This design creates no difficulty in UML, XML, and would be legal in all the target OO languages, but in fact in the JAXB XML mapping technology of Java it created a problem, and we have also found that it complicates our new JSON mapping. We issued guidance that we should avoid that pattern.

Should we go further than guidance and add a rule to Part 1 to prevent this kind of construct?

We should not prevent the creation of classes with the same name in different namespaces - the potential rule would only be about classes related by generalisation (directly or by a chain of multiple generalisations).

datexii commented 8 months ago

Comment 1930

Date: 2024-03-21 15:31:23 +0100 From: @JosefKaltwasser

I think this name clash (same name between class and ancestor) is a rare breed. The reason why we encountered it #251 is Jörg's attempt to implement a 'hook'. He thought it would be preferable to use the same name so that you could trace the hook when LocationReferencing is plugged together with Common. Other people have implemented hooks differently. This shows that we need an agreement on how to implement such 'hooks' before people can start generating v4 models. I personally don't feel that using the same name is important or valuable. Think about our most famous hook in Common: PayloadPublication. Whatever concrete publication type you find in any of the models only shares part of the name (...Publication). We could apply the same here and the problem would disappear. I am not in favour of inventing rules in Part 1 that handle specific problems of one or few downstream tools. I would rather go for guidelines for JAXB here (maybe when we move to GitHub, we could also launch a FAQ section?).

datexii commented 8 months ago

Comment 1931

Date: 2024-03-21 15:46:43 +0100 From: @iancornwellmottmac

The prompt for my raising this was that it seemed to be the thing that triggered the use of a namespace prefix in the new JSON mapping, added to every single specialized class, which may not be needed if we say that the pattern is not allowed. If we were able to remove the namespace prefix from every specialized class, that would be an improvement for all namespaces no matter whether the construct is actually used anywhere in our v4 models.

datexii commented 8 months ago

Comment 1933

Date: 2024-03-22 12:12:35 +0100 From: @JosefKaltwasser

I'm not convinced by this argument. The need described in the new JOSN mapping for polymorphism is similar to how we refer to types today in xml. If an attribute is typed with a class that has subclasses, these are referred with the namespace prefix in front of the class name. In XML, we create an element and depict the concrete type with the xsi:type statement, giving the same information (just with a ':' between namespace prefix and class name). Obviously it is not nice to have to give this long list of options for 'oneof' statements, but that is due to the limitations of the target platform to handle polymorphism.

JosefKaltwasser commented 3 months ago

Closed after further discussion via mails on the TB reflector on 21/21 August 2024.