sequence, sequence

[skinkie]

I just notice that OnwardTimingLink_DerivedViewStructure has a sequence, sequence, is this a bug?

https://github.com/NeTEx-CEN/NeTEx/pull/285/files#diff-70b0173f5ac6c906d3d98d0b4981773743227e970909ebcee169eb217cafa45fR551

[Aurige]

I just checked: in this specific case you can remove the nested <sequence> (it does not change the content and would be nicer modeling)... but you cant' to it everywhere ! This is the XML Spy view as it is now

And the one where one level of nested <sequence> is removed

I also checked that there was not other XSD Restriction with base="OnwardTimingLinkView" elsewhere

So no pb here... but this depends on what structure the XSD Restriction is based on: if the original version have nested <sequence> (with elements in between, for example due to the use of some Groups, etc.) and you want to keep some elements of the lower level of nesting but not the others, then you will end up with such nested without any element in-between

[skinkie]

@Aurige can you functionally define where the duplicate should stay? I already defined a nice pcregrep query to find all the variants. If we can make the schema more simple in this way, I would love to take that opportunity.

[Aurige]

If you extract all the empty nesting, then we can check them... but I don't see how to avoid a manual check (one by one) ... but if this is not hundreds of them, it is doable

[skinkie]

If you extract all the empty nesting, then we can check them... but I don't see how to avoid a manual check (one by one) ... but if this is not hundreds of them, it is doable

There are recurring patterns. So if you state this pattern cannot be simplified, then we don't even try on that pattern.

The following pattern EntityInVersionGroup, DataManagedObjectGroup, ... is quite common. If you have a hint why this one can or can't be replaced, please let me know.

<xsd:element name="RailwayJunction" abstract="false" substitutionGroup="InfrastructurePoint">
        <xsd:annotation>
                <xsd:documentation>A type of INFRASTRUCTURE POINT used to describe a RAILWAY network.</xsd:documentation>
        </xsd:annotation>
        <xsd:complexType>
                <xsd:complexContent>
                        <xsd:restriction base="RailwayJunction_VersionStructure">
                                <xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="EntityInVersionGroup" minOccurs="0"/>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="DataManagedObjectGroup"/>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="PointGroup"/>
                                        </xsd:sequence>
                                </xsd:sequence>
                                <xsd:attribute name="id" type="RailwayPointIdType">
                                        <xsd:annotation>
                                                <xsd:documentation>Identifier of RAILWAY JUNCTION.</xsd:documentation>
                                        </xsd:annotation>
                                </xsd:attribute>
                        </xsd:restriction>
                </xsd:complexContent>
        </xsd:complexType>
</xsd:element>

This one has a restriction.

<xsd:element name="VehicleJourneyWaitTime" abstract="false" substitutionGroup="JourneyTiming">
        <xsd:annotation>
                <xsd:documentation>The time for a vehicle to wait at a particular TIMING POINT IN JOURNEY PATTERN on a specified VEHICLE JOURNEY. This wait time will override the JOURNEY PATTERN WAIT TIME.</xsd:documentation>
        </xsd:annotation>
        <xsd:complexType>
                <xsd:complexContent>
                        <xsd:restriction base="VehicleJourneyWaitTime_VersionedChildStructure">
                                <xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="EntityInVersionGroup" minOccurs="0"/>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="VersionedChildGroup"/>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="JourneyTimingGroup"/>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="JourneyWaitTimeGroup"/>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="VehicleJourneyWaitTimeGroup"/>
                                        </xsd:sequence>
                                </xsd:sequence>
                                <xsd:attribute name="id" type="VehicleJourneyWaitTimeIdType"/>
                        </xsd:restriction>
                </xsd:complexContent>
        </xsd:complexType>
</xsd:element>

[skinkie]

@Aurige another nice complex one; I am specifically interested in the keyList double one.

<xsd:element name="CappingRule" abstract="false" substitutionGroup="PriceableObject_">
        <xsd:annotation>
                <xsd:documentation>Rule about capping for a mode.</xsd:documentation>
        </xsd:annotation>
        <xsd:complexType>
                <xsd:complexContent>
                        <xsd:restriction base="CappingRule_VersionedChildStructure">
                                <xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="EntityInVersionGroup" minOccurs="0"/>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:sequence>
                                                        <xsd:element ref="keyList" minOccurs="0">
                                                                <xsd:annotation>
                                                                        <xsd:documentation>A list of alternative Key values for an element.</xsd:documentation>
                                                                </xsd:annotation>
                                                        </xsd:element>
                                                        <xsd:element ref="Extensions" minOccurs="0"/>
                                                        <xsd:element ref="BrandingRef" minOccurs="0"/>
                                                </xsd:sequence>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="PriceableObjectGroup"/>
                                        </xsd:sequence>
                                        <xsd:sequence>
                                                <xsd:group ref="CappingRuleGroup"/>
                                        </xsd:sequence>
                                </xsd:sequence>
                                <xsd:attribute name="id" type="CappingRuleIdType"/>
                        </xsd:restriction>
                </xsd:complexContent>
        </xsd:complexType>
</xsd:element>

[Aurige]

for each of them, we need to check how the XXXof base="XXX" looks like and the check against what have been selected in the xsd:restriction to tell if we can, or not, remove the nested empty <xsd:sequence>

[skinkie]

So it cannot be generically stated that a restriction before a double sequence is allowed, but in other cases unwanted?

[Aurige]

unfortunately not... but if the number of cases is no too huge I'm ok to walk through them

[skinkie]

scan.txt

It is pretty long. So therefore I am asking for an heuristic.

[ue71603]

ah.. the list is here.... Guess we can do #287 anyhow.

[ue71603]

Discussion with Stefan: Check in XMLSpy whether there are types.

[ue71603]

removal should be tried.