noticeAssignments on JourneyParts and TrainBlock

[skinkie]

I guess this is missing in the model.

It obviously can be achieved using the NoticeAssignmentsInFrame.

[ue71603]

Do you want it in? For general same handling? If yes, pls assign it to @Aurige to tell us, if we do the PR

[skinkie]

I think I would want NoticeAssignment at the same 'level' as our new privateCodes.

[ue71603]

@Aurige should the PR be created?

[Aurige]

NoticeAssignment is already a first class object (and has a NoticesInFrameGroup), so you already can assign a Notice to whatever you want. I don't see a need for an additional mechanism doing the exact same thing in another way.

[skinkie]

If that is your standpoint, we will remove all noticeAssignments on all other places for 2.0. My preference would be available on DataManagedObject instead.

[Aurige]

I don't get your point Stefan... we don't need to change anything, it's already available

[skinkie]

I don't get your point Stefan... we don't need to change anything, it's already available

Some objects have noticeAssignments embedded, all objects can use the NoticesInFrameGroup. If your argument is: it is already available, then my rationale would be remove the embedded noticeAssignment and have a single way to do so. I think it would be better to remove the NoticesInFrameGroup instead, and have noticeAssignments available on all DataManagedObjects as embedded property.

[Aurige]

It's history ... it started with a few explicit Notice assignments, and then it was requested to make it available widely, and that's what we have now (but it was also decided not to deprecated to old explicit ones).
I would prefer avoiding such change at that point of the revision (especially since moving from a stand-alone noticeAssignment to one included in DataManagedObjects is quite a change for already existing implementations).

[skinkie]

We are switching major versions, good time to clean up.

[Aurige]

but we need to freeze the revision at some point ... I would really like to avoid new PR/Issues not being bug correction (or assign them to 3.0) so we can safely update the documentation.

[skinkie]

Then change the milestone.