Skip to content

VersionFrame

Nicholas Knowles edited this page Sep 16, 2020 · 10 revisions

Within a NeTEx XML Document, NeTEx data is organized within containers called VERSION FRAMEs.

There are different types of specific VERSION FRAME, each intended as a set of related data elements for a given functional area, for example;

A COMPOSITE FRAME can be used to group other frames (but frames cannot be nested otherwise). Within a specific frame, elements of different types (stops, lines, journeys, etc) are each grouped under a specific tag, usually named as the plural of the content element, for example , scheduledStopPoints, for a set of SCHEDULED STOP POINT elements. A GENERAL FRAME can contain any element in any order.

The data within a given frame should be consistent and coherent and is all subject to any VALIDITY CONDITIONs that attach to the frame.


Example

Here's an example of a simple SERVICE FRAME containing a LINE and two SCHEDULED STOP POINTS.

   <ServiceFrame version="1.0" id="epd:UK:myb:ServiceFrame_UK_PI_NETWORK:Line_3:myb" 
 			dataSourceRef="myb:Mybus" responsibilitySetRef="myb:tariffs">
 		<Name>Netwrok elements for Mybus Line 3</Name>
 	        <TypeOfFrameRef ref="fxc:UK:DFT:TypeOfFrame_UK_PI_NETWORK:FXCP" versionRef="fxc:v1.0"/>
		<codespaces>
			<CodespaceRef ref="naptStop_data"/>
		</codespaces>
		<prerequisites>
			<ResourceFrameRef version="1.0" 
					ref="epd:UK:MYBUS:ResourceFrame_UK_PI_COMMON:MYBUS:myb"/>
		</prerequisites>
		<!--==== LINEs ==== -->
		<lines>
			<Line version="1.0" id="myb:Line_3">
				<Name>Mybus 3</Name>
				<Description>Alpha - -Gamma</Description>
				<PublicCode>3</PublicCode>
				<PrivateCode type="noc_data">METR_1</PrivateCode>
				<OperatorRef version="1.0" ref="noc:MYBUS">137122</OperatorRef>
				<LineType>local</LineType>
				<PaymentMethods>cash</PaymentMethods>
			</Line>
		</lines>
		<!--==== STOP POINTs ==== -->
		<scheduledStopPoints>
			<ScheduledStopPoint version="naptStop:any" id="naptStop:4400CY0037">
				<Name>Alpha</Name>
				<TopographicPlaceView>
					<TopographicPlaceRef versionRef="nptg:any" ref="nptgLocality:E0056633"/>
					<Name>Barchester</Name>
					<QualifierName>Barsetshire</QualifierName>
				</TopographicPlaceView>
			</ScheduledStopPoint>
			<ScheduledStopPoint version="naptStop:any" id="naptStop:4400CY0038">
				<Name>Beta</Name>
				<TopographicPlaceRef versionRef="nptg:any" ref="nptgLocality:E0056633"/>
			</ScheduledStopPoint>
			<ScheduledStopPoint version="naptStop:any" id="naptStop:4400CY0039">
				<Name>Gama</Name>
				<TopographicPlaceRef versionRef="nptg:any" ref="nptgLocality:E0056633"/>
			</ScheduledStopPoint> 
		</scheduledStopPoints>
	</ServiceFrame>

Transmodel definition

A set of VERSIONs referring to a same DATA SOURCE and belonging to the same TYPE OF FRAME. A FRAME may be restricted by VALIDITY CONDITIONs.


Specific frame types


Further points

Organising Frames

Frames may indicate other frames as prerequisites.

Frame defaults

A number of different default values can be set on the frame to apply to all its content elements unless individually overridden (For example the CODESPACE and the currency to use for financial amounts. Frames may be classified with a TYPE OF FRAME - this can be useful to indicate the specific NeTEx PROFILE being used.

Tips & Hints

  • Place default values on the frame rather than repeating them on each element.
  • Specify an overall VALIDITY CONDITION condition on a COMPOSITE FRAME tto indicate that all the data in it is subject to the same condition. Note that this overall frame condition should not be confused with any contentValidityConditions for the frame - these declare shared conditions that are used by more than one specific element in the frame, but do not necessarily apply to all the elements in the frame.