Notes on the above example:

1. The Election element date and paId attributes uniquely identify the election. The paId is strictly an internal PA id and will remain constant for the election event. We use the same id in tests and live data.
2. The Council name and/or paId uniquely identifies the council, though council ids will not remain constant across separate elections.
3. The Council type attribute indicates the council authority type as follows:
   • Unitary
   • Metro
   • Non-Met
   • London
   • England (County council)
   • Scotland
   • Wales
4. The Council proportion element indicates the proportion of seats offered e.g. All up, Halves, Thirds. Should the council be subject to a boundary change, this is indicated by a boundaryChange attribute
5. The Party element provides the name and paId of the party nomination, with attributes that provide the seats currently held by the party, the seats offered for election, the number of unopposed returning candidates, and the total number of candidates standing.

Results

Results messages are sent as soon as the number of seats won by each nominated party is known, and summarise the structure of the council after these changes. Most importantly they reveal which party has held or gained control.

Live results messages for local councils follow the following filename pattern:

Local_result_{Council name}_{Revision}.xml

Whereas test messages follow the pattern:

Local_Test_result_{Council name}_{Revision}.xml

The revision number in the filename is incremented whenever a correction is made to the result, and starts from 1.

A result for a council uses a LocalElectionResult root element and adheres to the LocalResult.xsd

Here is an example of a result message from the 2015 Councils Election, using the filenameLocal_result_Amber_Valley_1.xml:

The results message repeats some of the information seen in the nominations message, but uses a new structure to convey the seats won by each party and new structure of the council. If there have been corrections to the result, the revision attribute in the root element will be incremented.

Notes on this message:

1. The Council element provides the same details as per nominations, but also provides attributes for the winning party, gain/hold control status, and the current sitting party.
2. The ElectedCouncillors elements provides a list of Party elements, for those parties that have won seats for their candidates. Each Party element provides the seats won figure.
3. The Changes element also offers a list of parties, detailing the seats change for each one via the Party change attribute.
4. Finally, the NewCouncil element provides a list of PartyElements that summarises the final structure of the council, with each Party element providing the total seats held by that party.

State of parties

At regular intervals a State of parties (SOP) message is generated, that summarises the council control gained, held and lost by the parties and the changes in seat totals. Each SOP message is generated for the number of results in so far, which is indicated by the SOP filename and within the message.

The SOP message may be generated for all councils (National), or just for councils in England, Scotland or Wales. The use of these types of regional SOP depends on the councils taking part in the election.

SOP messages for all councils follow the following filename pattern, where the ‘results total’ is the number of results so far, for all councils or a region:

Local_SOP_{Results total}.xml

Regional SOP messages follow a similar pattern, with the region of England, Scotland or Wales added e.g.

Local_SOP_England_{Results total}.xml

Whereas for a test the file format will be:

Local_Test_SOP_{Results total}.xml

or

Local_Test_SOP_England_{Results total}.xml

A SOP message uses the LocalStateOfParties root element and adheres to the LocalStateOfParties.xsd

Here is an example of a SOP message from the 2015 local council election, using the filename Local_SOP_279.xml:

Notes on this message:

1. The root LocalStateOfParties element provides the number of results so far out of a total number of councils.
2. Within the Parties element, the list of Party elements summarises the control and seats held by each party so far. Each Party element provides the total councils controlled by that party, the change in that control, the seats won so far and the change in seats.
3. Within the CouncilsIncluded element, a list of Council elements provides the councils for which there is a result so far. This has been shortened in the example above.
4. In SOP messages for all (National) councils the root LocalStateOfParties element will now have a region=”All” attribute. If this is not present, such as in older data, the assumption is that the SOP message is for all councils. Regional SOP messages will have a region attribute set to “England”, “Scotland” or “Wales” and will consider only those regional councils.

Making use of ‘PA IDs’ for elections, councils and parties

The XML message feed contains an enhancement which is not available in the other feed formats, namely unique ID numbers for each election, council and party. These can be relied upon to match data from nominations messages to results messages, and to uniquely identify different entities within a message. They cannot be used to match entities between elections though. Elections, councils and parties will have different PA ids between different elections.

However where the same parties are standing across different elections they are likely to have the same full name and abbreviation. Likewise, councils will have the same names unless changes have been necessary.