Complex type

EstimatedTimetableSubscriptionStructure

Defined in OpRa/SIRI/xsd/siri_estimatedTimetable_service.xsd:285

Subscription Request for the Estimated Timetable Service.

Base type

AbstractSubscriptionStructure

Used by elements

EstimatedTimetableSubscriptionRequest

Content model

Type structure

  • inherited from AbstractSubscriptionStructure 4 items
    • groupSubscriptionIdentityGroup 1..1

      Type for unique identifier of a subscription.

      • SubscriberRef 0..1 ParticipantRefStructure

        Participant identifier of Subscriber. Normally this will be given by context, i.e. be the same as on the Subscription Request.

      • SubscriptionIdentifier 1..1 SubscriptionQualifierStructure

        Identifier to be given to Subscription.

    • InitialTerminationTime 1..1 xsd:dateTime

      Requested end time for subscription.

    • SubscriptionRenewal 0..1 xsd:boolean

      By using this element, the subscriber asks the data provider for an extension of the InitialTerminationTime of the subscription. If SubscriptionRenewal is omitted, this request is to be treated as a re-subscription and therefore all data corresponding to the SubscriptionRequest must be sent in the initial response (or a portion of the data if MoreData is set to 'true'). (since SIRI 2.1)

  • Defined here
  • EstimatedTimetableRequest 1..1 EstimatedTimetableRequestStructure

    Request for information about the estimated timetable.

  • groupEstimatedTimetableSubscriptionPolicyGroup 1..1

    Parameters that affect the subscription publishing and notification processing.

    • IncrementalUpdates 0..1 xsd:booleandefault true

      Whether the producer should return the complete set of data, or only provide updates to the previously returned data i.e. changes to the expected deviation (delay or early time). Default is 'true'. If true only changes at the first stop will be returned and the client must interpolate the If false each subscription response will contain the full information as specified in this request (+(since SIRI 2.0)).

    • ChangeBeforeUpdates 0..1 DurationType

      The amount of change to the arrival or departure time that can happen before an update is sent (i.e. if ChangeBeforeUpdate is set to 2 minutes, the subscriber will not be told that a timetable is changed by 30 seconds - an update will only be sent when the timetable is changed by at least least 2 minutes. (OPtional from SIRI 2.0)

    • SkipRecordedCallUpdates 0..1 xsd:booleandefault false

      Indicates whether actual arrival-/departure times should be delivered as incremental updates, i.e. whether RECORDED CALL updates are transmitted immediately after an event occurs. (since SIRI 2.1) - 'false': Specifies that the data producer should transmit RECORDED CALL data, in particular actual arrival-/departure information as an incremental update immediately after an event occurs (with hysteresis taken into account) as is generally the case. The server will automatically proceed with 'false' if capability is not supported. - 'true': Can be requested if the data traffic is to be reduced and an immediate transmissions is not required in any of the consumer systems. 'true' specifies that the data producer should skip RECORDED CALL updates (if capability is supported after all), i.e., deliver them with the next update instead.
      - No specification: Default value 'false' applies (don't skip updates of recorded data).

    • IncludeOnlyRecordedCallUpdates 0..1 xsd:booleandefault false

      Indicates whether ONLY actual arrival-/departure times should be delivered. In other words, whether all updates related to ESTIMATED CALL should be skipped. (since SIRI 2.1) - 'false': Specifies that the data producer should transmit ESTIMATED and RECORDED CALL data as an incremental update immediately after an event occurs (with hysteresis taken into account) as is generally the case. The server will automatically proceed with 'false' if capability is not supported. - 'true': Can be requested if a consumer system is only interested in the actual times / recorded events because it only wants to check the performance for example. 'true' specifies that the data producer should only deliver RECORDED CALL udpates and skip ESTIMATED CALL updates (if capability is supported after all), i.e., deliver ESTIMATED CALL updates only with the next RECORDED CALL update.
      - No specification: Default value 'false' applies (don't skip updates of estimated data).

  • Extensions 0..1 ExtensionsStructure

    Extensions to schema. (Wrapper tag used to avoid problems with handling of optional 'any' by some validators).