Rename abstract complex types

[skinkie]

This pull request aims to resolve the task presented in #405

First it solves two complexTypes that should have been made abstract. The following will do the renaming.

I have renamed the _ suffix to _Abstract (instead of DummyType). I have also make sure that all those dummy types are now abstract="true". None of the examples fail.

[skinkie]

@Aurige I noticed that some of the "element ref" variants actually refer to an "dummy type". I guess this might be a bug in itself.

[skinkie]

I guess the real conversation should be:

1. what should be the suffix, should it be called _DummyType or would _Abstract cover the case better?
2. is it correct that the _DummyType must always be abstract="true" but abstract="true" should not have to be a _DummyType?
3. should we suffix the true abstract elements (for whatever reason) with a suffix too?
4. how is it possible that DummyTypes are used as element ref="blabla_DummyType"?

[ue71603]

Pls make sure that this does not result in all documentation needing a do over.

@trurlurl

[skinkie]

Pls make sure that this does not result in all documentation needing a do over.

@trurlurl

If it does not chang elementnames, it should never do so.

[Aurige]

@Aurige I noticed that some of the "element ref" variants actually refer to an "dummy type". I guess this might be a bug in itself.

Not sure: this was possibly done to be able to ref any specialisation of the dummy type (I need to check)

[skinkie]

@Aurige just to verify. You agree we call everything "_Abstract" that is abstract (not DummyType)? And everything that is used as such specialisation should be abstract?

[nick-knowles]

I guess the real conversation should be:
what should be the suffix, should it be called _DummyType or would _Abstract cover the case better?
is it correct that the _DummyType must always be abstract="true" but abstract="true" should not have to be a _DummyType?
+Yes dummy type should always be abstract, and _Abstract is okay and probably better than _Dummy.

should we suffix the true abstract elements (for whatever reason) with a suffix too?
+No. In many cases (the normal case) the simple abstract type can be used as the substitution class on subtypes without introducing a dummy type

I think we want to specifically mark the subset of cases where we have had to introduce a dummy type in order to make the XML substitution mechanism work. It may be at some future point we can revise this or resolve what the XML spy issue is.

how is it possible that DummyTypes are used as element ref="blabla_DummyType"?
Sounds odd - should review individual cases. Where does this happen

[skinkie]

@nick-knowles

Very simple example. If you would consider Call_ a dummy, but Call_ is actually used within calls_RelStructure. In this case there is a single Call remaining, I think Call_ can actually be removed.

        <xsd:complexType name="calls_RelStructure">
                <xsd:annotation>
                        <xsd:documentation>CALLs associated with entity.</xsd:documentation>
                </xsd:annotation>
                <xsd:complexContent>
                        <xsd:extension base="strictContainmentAggregationStructure">
                                <xsd:sequence>
                                        <xsd:element ref="Call_" minOccurs="2" maxOccurs="unbounded"/>
                                </xsd:sequence>
                        </xsd:extension>
                </xsd:complexContent>
        </xsd:complexType>
        <xsd:element name="Call_" type="VersionedChildStructure" abstract="true">
                <xsd:annotation>
                        <xsd:documentation>Dummy CALL.</xsd:documentation>
                </xsd:annotation>
        </xsd:element>

Similarly CellRef_ is a dummy, it is used in seriesConstraintPrices_RelStructure. Is only used in CellRef_.

        <!-- === DUmmy Cell Ref ====================================================== -->
        <xsd:element name="CellRef_" type="VersionOfObjectRefStructure" abstract="true" substitutionGroup="VersionOfObjectRef">
                <xsd:annotation>
                        <xsd:documentation>Dummy Reference to a FARE TABLE CELL.</xsd:documentation>
                </xsd:annotation>
        </xsd:element>


        <xsd:complexType name="seriesConstraintPrices_RelStructure">
                <xsd:annotation>
                        <xsd:documentation>Type for a list of SERIES CONSTRAINT PRICEs.</xsd:documentation>
                </xsd:annotation>
                <xsd:complexContent>
                        <xsd:extension base="strictContainmentAggregationStructure">
                                <xsd:choice maxOccurs="unbounded">
                                        <xsd:element ref="SeriesConstraintPriceRef"/>
                                        <xsd:element name="SeriesConstraintPrice" type="SeriesConstraintPrice_VersionedChildStructure">
                                                <xsd:annotation>
                                                        <xsd:documentation>A set of all possible price features of a SERIES CONSTRAINT: default total price, discount in value or percentage etc.</xsd:documentation>
                                                </xsd:annotation>
                                        </xsd:element>
                                        <xsd:element ref="CellRef_"/>
                                </xsd:choice>
                        </xsd:extension>
                </xsd:complexContent>
        </xsd:complexType>

        <xsd:element name="CellRef" type="CellRefStructure" substitutionGroup="CellRef_">
                <xsd:annotation>
                        <xsd:documentation>Reference to a CELL.</xsd:documentation>
                </xsd:annotation>
        </xsd:element>

So Nick, regardless if these examples could be simplified (I guess!) should the dummy type be used as a ref?

Are examples that have ServiceAccessRight_, VehicleMeetingPointAssignment_, VehicleServicePlaceAssignment_, VehicleMeetingPlace_, FareContractEntry_, TravelSpecification_, SpotEquipment_ those must be checked. Because they are not abstract.

[nick-knowles]

Wil answer one at a time...

Very simple example. If you would consider Call_ a dummy, but Call_ is actually used within calls_RelStructure. In this case there is a single Call remaining, I think Call_ can actually be removed.

Call_ is used oresumably so that both CALL and DATED CALL can be used within Calls_Rel.
XML SPY wont let CALL BE a substitution group for DATED CALL , even though DATED CALL is a subtype of CALL

This allows a service journey to have either CALLS or DATE CALLS. Strictly speaking this is wrong - DATED CALLS should be used in a DATED VEHICLE JOURNEY and not a SERVICE JOURNEY. It probably is an hack from long ago before there was a separate datedCalls_RelStructure and a separate DATED VEHICLE JOURNEY

Would try the following:
a) Change calls_RelStructure. to reference only CALL and not CAlL_ / DATED CALL
b) validate all the examples. If they validate then the drop CALL_ and use CALL instead

Note though that dropping DATED CALL from service journey might cause breakage for certain users...

[nick-knowles]

Similarly CellRef_ is a dummy, it is used in seriesConstraintPrices_RelStructure. Is only used in CellRef_.

    <!-- === DUmmy Cell Ref ====================================================== -->
    <xsd:element name="CellRef_" type="VersionOfObjectRefStructure" abstract="true" substitutionGroup="VersionOfObjectRef">
            <xsd:annotation>
                    <xsd:documentation>Dummy Reference to a FARE TABLE CELL.</xsd:documentation>
            </xsd:annotation>
    </xsd:element>

This is being done to avoid circular / forward dependencies between packages. .

The FarePrice package defines core abstract price concepts. These are extended in dependent packages. eg for FareTable Rows and Cells. So it is legitimate

[nick-knowles]

VehicleMeetingPointAssignment_, VehicleServicePlaceAssignment_, VehicleMeetingPlace_, FareContractEntry_, TravelSpecification_, SpotEquipment_ those must be checked. Because they are not abstract.

Agree these should all be abstract.

[skinkie]

Replaced by #939