[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

noticeAssignments on JourneyParts and TrainBlock #736

Open
skinkie opened this issue Jun 1, 2024 · 11 comments
Open

noticeAssignments on JourneyParts and TrainBlock #736

skinkie opened this issue Jun 1, 2024 · 11 comments
Assignees
Labels
enhancement non semantic enhacement: technical enhancement, etc.
Milestone

Comments

@skinkie
Copy link
Contributor
skinkie commented Jun 1, 2024

I guess this is missing in the model.

It obviously can be achieved using the NoticeAssignmentsInFrame.

@skinkie skinkie added the enhancement non semantic enhacement: technical enhancement, etc. label Jun 1, 2024
@ue71603 ue71603 added this to the netex_2.0 milestone Jun 5, 2024
@ue71603
Copy link
Contributor
ue71603 commented Jun 22, 2024

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
Copy link
Contributor Author
skinkie commented Jun 22, 2024

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

@ue71603 ue71603 assigned Aurige and unassigned skinkie Jun 22, 2024
@ue71603
Copy link
Contributor
ue71603 commented Jun 22, 2024

@Aurige should the PR be created?

@Aurige
Copy link
Contributor
Aurige commented Jun 24, 2024

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
Copy link
Contributor Author
skinkie commented Jun 24, 2024

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
Copy link
Contributor
Aurige commented Jun 24, 2024

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

@skinkie
Copy link
Contributor Author
skinkie commented Jun 24, 2024

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
Copy link
Contributor
Aurige commented Jun 24, 2024

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
Copy link
Contributor Author
skinkie commented Jun 24, 2024

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

@Aurige
Copy link
Contributor
Aurige commented Jun 24, 2024

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
Copy link
Contributor Author
skinkie commented Jun 24, 2024

Then change the milestone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement non semantic enhacement: technical enhancement, etc.
Projects
None yet
Development

No branches or pull requests

5 participants