tefra
Generate classes for element groups
I am currently reviewing the output of the ambigious branch and main and I notice something odd. Consider the TargetTimesAtStopGroup. I really believe this is not right.
Source file ./xsd/netex_part_2/part2_journeyTimes/netex_datedPassingTimes_version.xsd
This should become something like a choice between two types. But instead each element becomes part of the choice.
<xsd:group name="TargetPassingTimeGroup">
<xsd:annotation>
<xsd:documentation>TARGET PASSING TIME elements.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:choice>
<xsd:group ref="TargetTimesAtStopGroup">
<xsd:annotation>
<xsd:documentation>Aimed Times at stop.</xsd:documentation>
</xsd:annotation>
</xsd:group>
<xsd:group ref="NonStopTimesAtStopGroup"/>
</xsd:choice>
<xsd:element name="AimedHeadway" type="HeadwayIntervalStructure" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Aimed Frequency of service.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:group>
<xsd:group name="TargetTimesAtStopGroup">
<xsd:annotation>
<xsd:documentation>Times at stop elements.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="AimedArrivalTime" type="xsd:time" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Aimed Arrival time.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ArrivalDayOffset" type="DayOffsetType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Arrival Day Offset from Start of Journey. </xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="AimedDepartureTime" type="xsd:time" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Aimed departure time.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="DepartureDayOffset" type="DayOffsetType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>DepartureDay Offset from Start of Journey. </xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="AimedWaitingTime" type="xsd:duration" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Aimed waiting interval.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:group>
This becomes:
@dataclass(kw_only=True)
class TargetPassingTimeViewStructure(PassingTimeViewStructure):
"""
Type for Simplified TARGET PASSING TIME.
:ivar choice:
:ivar aimed_headway: Aimed Frequency of service.
"""
class Meta:
name = "TargetPassingTime_ViewStructure"
choice: List[
Union[
"TargetPassingTimeViewStructure.AimedArrivalTime",
"TargetPassingTimeViewStructure.ArrivalDayOffset",
"TargetPassingTimeViewStructure.AimedDepartureTime",
"TargetPassingTimeViewStructure.DepartureDayOffset",
XmlDuration,
"TargetPassingTimeViewStructure.AimedNonstopPassingTime",
"TargetPassingTimeViewStructure.PassingDayOffset",
]
] = field(
default_factory=list,
metadata={
"type": "Elements",
"choices": (
{
"name": "AimedArrivalTime",
"type": Type[
"TargetPassingTimeViewStructure.AimedArrivalTime"
],
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "ArrivalDayOffset",
"type": Type[
"TargetPassingTimeViewStructure.ArrivalDayOffset"
],
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "AimedDepartureTime",
"type": Type[
"TargetPassingTimeViewStructure.AimedDepartureTime"
],
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "ArrivalDayOffset",
"type": Type[
"TargetPassingTimeViewStructure.ArrivalDayOffset"
],
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "AimedDepartureTime",
"type": Type[
"TargetPassingTimeViewStructure.AimedDepartureTime"
],
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "DepartureDayOffset",
"type": Type[
"TargetPassingTimeViewStructure.DepartureDayOffset"
],
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "AimedWaitingTime",
"type": XmlDuration,
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "AimedNonstopPassingTime",
"type": Type[
"TargetPassingTimeViewStructure.AimedNonstopPassingTime"
],
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "PassingDayOffset",
"type": Type[
"TargetPassingTimeViewStructure.PassingDayOffset"
],
"namespace": "http://www.netex.org.uk/netex",
},
),
"max_occurs": 5,
},
)
aimed_headway: Optional[HeadwayIntervalStructure] = field(
default=None,
metadata={
"name": "AimedHeadway",
"type": "Element",
"namespace": "http://www.netex.org.uk/netex",
},
)
Groups of elements are flattened @skinkie so it becomes a choice of two sequences
Groups of elements are flattened @skinkie so it becomes a choice of two sequences
Which is obviously not what was intended. What should be used if I would like to see them as a choice between two sets of elements?
When reading the code the code now flattens groups, and then removes them.
I have created this rather simple form of the use case.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.netex.org.uk/netex" xmlns:netex="http://www.netex.org.uk/netex" xmlns:siri="http://www.siri.org.uk/siri" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.netex.org.uk/netex" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.1" id="netex_datedPassingTimes_version">
<xsd:element name="Test">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:group ref="TargetTimesAtStopGroup">
<xsd:annotation>
<xsd:documentation>Aimed Times at stop.</xsd:documentation>
</xsd:annotation>
</xsd:group>
<xsd:group ref="NonStopTimesAtStopGroup"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:group name="TargetTimesAtStopGroup">
<xsd:annotation>
<xsd:documentation>Times at stop elements.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="AimedArrivalTime" type="xsd:time" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Aimed Arrival time.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="AimedDepartureTime" type="xsd:time" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Aimed departure time.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="AimedWaitingTime" type="xsd:duration" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Aimed waiting interval.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:group>
<xsd:group name="NonStopTimesAtStopGroup">
<xsd:annotation>
<xsd:documentation>Times at stop elements.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="AimedNonstopPassingTime" type="xsd:time" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Aimed PASSING TIME if doesn't stop at TIMING POINT.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:group>
</xsd:schema>
I am looking for something like this as the output:
"choices": (
{
"name": "TargetTimesAtStopGroup",
"type": Type[
"TargetTimesAtStopGroup"
],
"namespace": "http://www.netex.org.uk/netex",
},
{
"name": "NonStopTimesAtStopGroup",
"type": Type[
"NonStopTimesAtStopGroup"
],
"namespace": "http://www.netex.org.uk/netex",
},
I guess for this to happen the analyser should mark groups within a choice as something special, to later upgrade them into a type which would get its own class.
Yeah and the xml parser/serializer has to recognize and ignore the group classes. We would need to implement something like the wrappers but for groups.
Honestly I don't like the approach. xsdata philosophy is to simplify xml schemas not replicate all their quirks into python. Some of them like circular references would be impossible to tackle otherwise.
I am going to leave this issue open as a feature request, but don't hold your breath.
Yeah and the xml parser/serializer has to recognize and ignore the group classes. We would need to implement something like the wrappers but for groups.
Thanks, I'll investigate.
Honestly I don't like the approach. xsdata philosophy is to simplify xml schemas not replicate all their quirks into python. Some of them like circular references would be impossible to tackle otherwise.
My aim for this project would be to have an object-oriented output of an XML Schema. The flattening is, where there is more than one group, does not do just to the XML Schema in this particular case. I can find some other cases where it certainly makes sense to flatten it. (AllSubModeChoiceGroup)
I am going to leave this issue open as a feature request, but don't hold your breath.
I have just researched how and when this is done within the NeTEx schema, it is not that often. https://github.com/NeTEx-CEN/NeTEx/issues/669
I have zero interest in this one, it goes against the architecture of the cli to always simplify the generated models.
Although If someone manages to implement it behind a configuration flag, I will gladly accept the contribution