Closed skinkie closed 1 year ago
I am working (for some time now) on massive refactor for compound fields, to resolve this kind of issues with nested choices/sequences and groups.
I am working (for some time now) on massive refactor for compound fields, to resolve this kind of issues with nested choices/sequences and groups.
Consider this bug a 'how to reproduce' not to pressure you into releasing anything that is not production ready.
Hey @skinkie, the refactor I mentioned is now on master, please take a look.
The bug part where occurs where wrongly calculated should now work as expected :crossed_fingers:
I am closing this one for now, if you still have an issue let's open a new one, with the new generated classes.
I am trying to cleanup the issues.
Considering schema: https://github.com/VDVde/OJP/tree/changes_for_v1.1
Generating this schema with compound-fields.
Having XML below. The query:
ojp.ojprequest.service_request.ojpfare_request[0].trip_fare_request.trip.leg[2].timed_leg.service.choice_1
leads to the following:Given that this element upstream is a choice (that is not very elegant in my humble option...) the way xsData handles that in deserialisation looses track what element was actually in use here. Hence I would have no clue what this InternationalText comes from. Ideally I would like to see that this choice would become a dictionary or list of tuples but at least the element name.
Suggestion 1: Could choice_1 be renamed to the actual choice? For example in the case below I would rather have it named datedjourneygroup and privateservicegroup.
Bug 1: I think the group under a choice is wrongly interpreted as generating a list of elements being a choice. This is not the case. The group as a whole is 'the choice'. My suggestion here is introduce the group as 'artifical container' which is now choice_1 (or choice_2). Skipping the compound fields