Required IdType fixes
This pull request tries to address the missing required "id" attributes. This is selected by:
- GeneralFrameMembers (they must have id, no question)
- Keyrefs that are already modelled in the NeTEx_publication file
I may have added too many, which I certainly will review. For the following objects there are IdTypes defined, but there is no individual id attribute modelled, this should still be done.
CustomerService
Entrance
FareContractEntry_
GeneralFrameMember
OtherOrganisation
PassengerCarryingRequirementsView
PassingTimeView
Point
ServiceAccessRight_
SignEquipment
TravelSpecification_
TypeOfEntity
VehicleMeetingPlace_
Zone
PassingTimeView and PassengerCarryingRequirementsView are likely a bug in the schema that introduces them in the GeneralFrame. For PassingTimeView a DataManagedObjectView is first introduced, and never used after. For PassengerCarryingRequirementsView in my guess invalidly a DataManagedObject is used (see: #474)
Failing examples must be fixed. Already checked with the cardinality in the documentation.
fixed all assigned tasks
I'm not sure that we can be so systematic ! A commented in other PR, I agree that any standalone object that can be referenced should be enforced to have an Id, but when it's an object that is embedded in the XML hierarchy and that will never be referenced, this constraint does not really makes sense (also it is harmless ... except that it brakes existing data).
For example, take the very first example you had to update : the <LimitingRuleInContext> is embedded, and giving it an Id is a constraint that is useless.
I will add this as a discussion point fir next meeting.
@ue71603 in essence this is the problem with order in https://github.com/skinkie/reference/issues/65 so if we on one hand have defined it as key element and thus compound key, and in the XML Schema it is optional. That is never going to work.
In my view objects have id. One does not know if it will be referenced. They also may not be generated at the same time in the same process.