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

Understanding the implications of choice/groups #669

Open
skinkie opened this issue Feb 28, 2024 · 3 comments
Open

Understanding the implications of choice/groups #669

skinkie opened this issue Feb 28, 2024 · 3 comments
Assignees
Labels
bug Technical mistake, inconsistency with the documentation, etc. enhancement non semantic enhacement: technical enhancement, etc. help wanted question
Milestone

Comments

@skinkie
Copy link
Contributor

skinkie commented Feb 28, 2024

In the NeTEx schema choices are sometimes used as a container for groups. If we take a simple example like the CodeRangeGroup. It is to me unclear why a choice is actually used. Wasn't the intention to get the StartValue and EndValue? Or was the intention to choose from either of one.

https://github.com/NeTEx-CEN/NeTEx/blob/master/xsd/netex_framework/netex_genericFramework/netex_organisation_version.xsd#L786

Another variant can be observed in the AllSubmodeChoiceGroup. This variant expects the user to choose an element from either the PtSubmodeChoiceGroup or the PrivateSubmodeChoiceGroup.

https://github.com/NeTEx-CEN/NeTEx/blob/master/xsd/netex_framework/netex_reusableComponents/netex_submode_version.xsd#L86

A different variant of combinations appear in TargetPassingTimeGroup, ObservedPassingTimeGroup, EstimatedPassingTimeGroup. In my perspective these three objects are wrongfully using a choice.

https://github.com/NeTEx-CEN/NeTEx/blob/master/xsd/netex_part_2/part2_journeyTimes/netex_datedPassingTimes_version.xsd#L148
https://github.com/NeTEx-CEN/NeTEx/blob/master/xsd/netex_part_3/part3_monitoring/netex_monitoredPassingTimes_version.xsd#L148
https://github.com/NeTEx-CEN/NeTEx/blob/master/xsd/netex_part_3/part3_monitoring/netex_monitoredPassingTimes_version.xsd#L262

When we consider SiteConnectionEndStructure which gives us a choice of groups. In this case all sub elements, given they are part of the same group, may be added. Given that the groups are not elements, no natural grouping would surface. It wouldn't give the implementer any guidance if it would treat it with the same 'flattening' strategy as the AllSubmodeChoiceGroup. I guess we can agree 'this is something different', how to identify this difference is the question.

https://github.com/NeTEx-CEN/NeTEx/blob/master/xsd/netex_part_1/part1_tacticalPlanning/netex_siteConnection_version.xsd#L159

Given that the list of exceptions is rather small, would like this to be resolved. I have ignored SIRI for now.

@skinkie skinkie added bug Technical mistake, inconsistency with the documentation, etc. enhancement non semantic enhacement: technical enhancement, etc. help wanted question labels Feb 28, 2024
@ue71603
Copy link
Contributor

ue71603 commented Feb 28, 2024

What we need to have is a construction guide line. Also for the structs etc that Christophe and Nick usually use. The distribution between xxx_version.xsd and xxx_support.xsd etc. Perhaps we start with markdown in the NeTEx wiki. Or does something like that exist?

@Aurige
Copy link
Contributor

Aurige commented Mar 12, 2024

in the CodeRangeGroup example, the choice is totally useless since it is a choice with 1 single element (the CodeRangeGroup .... the choice does not go through the Group, and it is not a choice between StartValue and EndValue). So this choice should be removed.

AllSubmodeChoiceGroup it is a way to combine 2 choices (PtSubmodeChoiceGroup and PrivateSubmodeChoiceGroup who are themselves choices) and the only way to do combine them to be a bigger choice is to include them in a choice.

For TargetPassingTimeGroup, it is either a TargetTimesAtStopGroup either a NonStopTimesAtStopGroup (the vehicle pass without stopping and just has a passing time) so it is perfectly Ok here.

And for the SiteConnectionEndStructure , the connection end is either a StopPlace (StopPlaceEndGroup), a PointOfInterest (PointOfInterestEndGroup) or a Parking (ParkingEndGroup)

So the first one is obviously a bug, but I don't see any ambiguity for the others.

@ue71603 ue71603 added this to the netex_2.0 milestone Apr 17, 2024
@ue71603
Copy link
Contributor

ue71603 commented Apr 17, 2024

@skinkie we just fix the first one? Or is something open?

@ue71603 ue71603 assigned skinkie and unassigned Aurige, ue71603 and trurlurl Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Technical mistake, inconsistency with the documentation, etc. enhancement non semantic enhacement: technical enhancement, etc. help wanted question
Projects
None yet
Development

No branches or pull requests

4 participants