ndr - interface dependency agreement... · greyhounds australasia national data repository (ndr)...

Greyhounds Australasia

National Data Repository (NDR)

Interface Dependency Agreement

Document ID:

Version: 1.2

Date: August 3 2012

Status: Approved – with Updates

`

Commercial-In-Confidence

NDR - Interface Dependency Agreement – v1.1 - January 2012 of 96

Table of Contents

1. Document Control ................................................................................................. 4

1.1. Document Owner ............................................................................................................ 4

1.2. Document Contribution List .............................................................................................. 4

1.3. Document History ............................................................................................................ 4

1.4. Stakeholder Signoff ......................................................................................................... 8

2. Introduction .......................................................................................................... 10

2.1. Document Purpose ........................................................................................................ 10

2.2. Intended Audience ........................................................................................................ 10

2.3. Document Scope ........................................................................................................... 10

2.4. Guiding Principles .......................................................................................................... 10

2.5. Decision Register ........................................................................................................... 11

2.6. Items Known to be Incomplete ...................................................................................... 15

3. Business Overview .............................................................................................. 17

3.1. Business Context ........................................................................................................... 17

3.2. Business Entities............................................................................................................ 18

3.3. Business Operations ...................................................................................................... 19

4. Logical Interface .................................................................................................. 22

4.1. Logical Data Model ........................................................................................................ 22

4.2. Data Ownership ............................................................................................................ 31

4.3. Logical Events ............................................................................................................... 33

5. Physical Interface ................................................................................................ 34

5.1. Web Services ................................................................................................................ 34

5.2. Encryption .................................................................................................................... 49

5.3. Authentication ............................................................................................................... 49

5.4. Change Detection .......................................................................................................... 50

5.5. Schemas ....................................................................................................................... 51

5.6. Validation ...................................................................................................................... 56

5.7. Status Codes ................................................................................................................. 57

`



6. End to End Scenarios .......................................................................................... 59

6.1. Success Scenarios ......................................................................................................... 59

6.2. Failure Scenarios ........................................................................................................... 61

7. Backwards Compatibility .................................................................................... 63

7.1. Operation...................................................................................................................... 63

7.2. Existing NDR files .......................................................................................................... 63

8. Definitions, Acronyms and Abbreviations ........................................................ 66

9. Reference Documents ......................................................................................... 67

10. Appendix: Use of ETags ..................................................................................... 68

11. Appendix: Description of Attributes .................................................................. 70

11.1. Attributes of Dogs ......................................................................................................... 70

11.2. Attributes of Litters ........................................................................................................ 72

11.3. Attributes of Meetings .................................................................................................... 73

11.4. Attributes of Persons ..................................................................................................... 76

11.5. Attributes of Groups ...................................................................................................... 77

12. Appendix: Description of Types ......................................................................... 78

12.1. Basic Types ................................................................................................................... 78

12.2. Types used across Entities ............................................................................................. 78

12.3. Types relating to Dogs and Litters .................................................................................. 78

12.4. Types relating to Meetings and Races ............................................................................. 84

12.5. Types relating to Persons and Groups ............................................................................. 93

12.6. Types relating to Events ................................................................................................ 95

`



1. Document Control

1.1. Document Owner

If you have any feedback, questions, or require an electronic copy of this document, please contact:

Author: Chris Hawken

Email: [email protected]

1.2. Document Contribution List

Name Title Key Areas

David Elias Consultant All

1.3. Document History

Version Date Author Version Update Details

0.1 August 2 2011 Idan Manor Initial Draft.

0.2 October 21 2011 David Elias Updated with Business Overview and description of Logical Interface.

0.3 October 26 2011 David Elias Draft circulated for comment.

0.4 October 28 2011 David Elias Document updated with feedback from Craig Taberner.

0.5 November 21 2011 David Elias Document updated based on feedback from State Bodies.

0.6 November 30 2011 David Elias Key changes in this version:

Section 2.5 Decision Register updated.

Section 4.1 Logical Data Model refined. Events added to Logical Data Model.

Section 4.2 Data Ownership refined.

Section 5.1 Web Services refined. Search methods (Identify) added.

Section 5.5 Schemas updated.

Previous Section 6 Service Level Requirements removed from this document. These will be specified in the contractual arrangement between the State Bodies and GA.

Section 10 Description of Types added to document. This section lists all types used in the Logical Data Model.

`




0.7 December 2 2011 David Elias Key changes in this version:

Section 2.5 Decision Register updated.

o Item 4: Multiple sires: Business impact updated.

o Item 8: NDR will store a history of previous owners and previous trainers of a Dog. This change is reflected in Sections 4.1.1 and 5.1.1.

o Item 16: Moving group: Noted that this is pending definition of Business Rules.

1.0 January 13 2012 David Elias Document baselined as representing the agreed position of all parties at the date of release.

Section 11 has been added to provide a description of the attributes of each Entity.

Substantial change to dog penalties. It is now possible to specify that a penalty requires a satisfactory trial. Any authority can clear a penalty, allowing the possibility of a satisfactory trial being performed in a state other than the one that originally issued the penalty. Affects Section 2.5 (decision 15), Section 4.2.2, 5.1.1, 11.1, 0 and the schemas types.xsd, dog.xsd, dog_in.xsd, dog_penalty.xsd.

At the suggestion of WA, modified Dog Lifestate to clearly distinguish “retired” and “deceased”, and to add extra reasons for each. Affects Section 12.3 and the schema types.xsd.

At the request of Queensland: Added Novice to Dog Grade Type. Affects Section 12.3 and the schema types.xsd.

At the request of GA: Added “service method” (i.e. natural / FSI) to Litter Entity. Affects Sections 4.1.2, 12.3 and the schemas types.xsd, litter.xsd, litter_in.xsd. In addition, added details for a FSI service, including inseminator, facility name, breeding unit ID. Affects Sections 4.1.2 and 12.3, and the schemas types.xsd.

Explanatory Material: Section 6.1.1. Added description of the End to End Process for Assigning / Updating a Dog Name.

Minor correction: Added the correct type (i.e. Dog Name Type) to Dog names in Figure 3 and Figure 5.

Minor amendments to phone numbers: Extended phone type to allow domestic or international phone numbers. Mobile number changed to non-mandatory. Affects Sections 4.1.4, 12.5 and schemas types.xsd, person.xsd, person_in.xsd.

`




Modified API to reflect the fact that all events will be published to the same queue. Affects Sections 5.1.1-5.1.6.

Removed redundant authority field from person_penalty.xsd.

Minor change to Litter entity to include the name of the breeder. Affects Section 4.1.2 and schemas litter.xsd, litter_in.xsd, litter_whelping.xsd.

Extended maximum margin to 40 lengths, in increments of 0.25 between 1 and 5; increments of 0.5 between 5 and 10; increments of 1 between 11 and 40. Affects Section 0 and schema types.xsd.

At the request of WA, the time of an individual dog in a race result is now optional. Affects Section 4.1.3 and the schemas meeting_in.xsd, meeting.xsd.

1.1 January 31 2012 David Elias Functional modifications:

o Modified FSI Details Type to allow multiple Breeding Units. Affects Sections 11.2, 12.3, and the schema types.xsd

o Modified Dogs in Race to include a link to the Owner of the Dog (at the time of the race). Affects Section 4.1.3 (Figure 5), and the schema meeting_in.xsd.

o Modified the interface to the Dog - Update

(trainer) transaction to allow the removal of the current Trainer, without assigning a new Trainer. Affects Section 5.1.1.

o As agreed between WA and GRV: Added the following fields to the data recorded when a Dog completes a Satisfactory Trial: Distance, Number of Runners, Box No, Weight, Time, Place, Margin. Affects Section 12.3, and the schema types.xsd.

o Margin Type modified to allow a margin of “0”. Affects Section 12.4, and the schema types.xsd.

Modifications to facilitate data migration:

o Modified Person Name Type to make Middle Initial optional: affects the schema types.xsd.

o Added Box Type and Rug Type as enumerations, mainly to allow “unknown” box no and rug no: affects Section 4.1.3 (Figure 5), Section 12.4, and the schema types.xsd.

o Modified Margin Type, Race Result Type, Dog Grade Type to allow “unknown”: affects

`




Sections 12.3-12.4, and the schema types.xsd.

o Within Dog Race Result, margin is made optional (aligned with the attribute time). Affects Section 4.1.3 (Figure 5), and the schema race.xsd.

o Race Result Info Type modified so that all fields non-mandatory. Affects schema types.xsd.

Cosmetic changes:

o Modified names in Figure 2 to match text.

o Modified Figure 3 and Figure 5 to clearly

show a Person or Group can own a Dog.

Modified description of Event / Meta data:

o Included API functions to read metadata. Affects Sections 5.1.1 - 0.

o Removed the schema event_extension.xsd. Affects Section 5.5.3.

o Included the schema: meta.xsd. Affects Section 5.5.4.

o Modified Event Type to match implementation. Affects Section 12.6 and schemas types.xsd.

o Added Event Details Type. Affects Section 12.6 and the schema types.xsd.

1.11 July 3 2012 Chris Hawken Updated Litter API – Should be Sire then Dam for Earbrand

1.2 August 3 2012 Chris Hawken Update Decision Register (section 2,5) with outcomes from NDR meeting held in Melbourne on 27th June 2012

Update Items Known to be Incomplete (section 2.6) with outcomes from NDR meeting held in Melbourne 27th June 2012

Remove embedded schema documents (section 5.5) from the IDA document. Schemas now available on NDR homepage.

Added Backwards Compatibility (section 7)

Split into separate elements within the race schema PIR and comments (section 11.3 and 12.4)

Add split rug number element to the Result in the races schema (section 11.3 and 12.4)

`




Separate out results (section 11.3) between dogs that:

o Do not start in a race

o Do not finish a race

o Finish a race and given a placing

Added email address to person schema (section 11.4)

Removed Unknown Dog Grade Type value (section 12.2)

Removed Unknown Rug Type value (section 12.4)

Removed Unknown Box Type value (section 12.4)

Changed Margin from enumerated type to decimal value (section 12.4). Margins no longer need to be rounded.

Removed Injured and Unknown Race Result Type value (section 12.4)

Sorted Track Code Type values (section 12.4)

Changed Dapto code (DAP) to DTO (section 12.4)

Changed BGC track name from Brisbane to Albion Park(section 12.4)

Added track code INT International (section 12.4)

Add 31 Race Grade Type values to cover missing and New Zealand grades

Added PersonUpdateGroupMembership Event Type (section 12.6)

Remove “Identify” Business Operation from each API in section 5.1.

Removed “Unassigned” from the Box Type value (section 12.4)

Added to Lifestate “Retired” reason of “Other” (section 12.3)

1.4. Stakeholder Signoff

Name Title Sign-Off

Received (Yes / No)

Date

Craig Taberner CEO GA

Geoff Milner GRV Project Sponsor

Mark Bottcher Manager Greyhound Racing

Racing and Wagering Western

Yes 23/12/2011

`



Australia

(on behalf of NSW, WA)

Stuart Cashen NZGRA Yes 7/12/2011

David Rowan GRQ Yes 8/12/2011

(Other State Bodies will

need to nominate appropriate Stakeholders)

`



2. Introduction

2.1. Document Purpose

This Interface Dependency Agreement (IDA) describes the interface provided by the National Data Repository (NDR).

2.2. Intended Audience

This document is intended to be used by:

Development and test teams of all parties (both within GA and State Bodies) who interact with the

NDR via the interface.

2.3. Document Scope

2.3.1. Inclusions

A description of the Logical Interface provided by the NDR;

A specification of the Physical Interface provided by the NDR;

Data Validation rules applied by the NDR;

Description of error scenarios, and best practices to assist in resolving errors.

2.3.2. Exclusions

Any item not explicitly listed as being within scope.

2.4. Guiding Principles

The National Data Repository (NDR) is the master repository for greyhound data that is common between GA and the State Bodies.

The following principles are used to guide decisions concerning what data should be stored in the NDR, how it should be named, and how it should be accessed.

# Principle Business Impact Approved By

Date

1 The NDR will store the minimum of

data that needs to be common between GA and the State Bodies.

GA and each State Body will have

to maintain their own data repository for specific needs which

are not met by the NDR.

2 The NDR will use naming conventions that are meaningful

Bodies will have to use NDR naming when communicating with

`



# Principle Business Impact Approved By

Date

across jurisdiction boundaries. the NDR, which may require

converting from a local naming convention.

3 Every data item stored in the NDR

has an Owning Authority.

Only the Owning Authority of a

data item is able to modify the data item. (Note: There are some

specific exceptions to this rule,

which are specified later in the document.)

4 Regardless of Owning Authority, all data stored in the NDR is readable

by GA and every State Body.

5 When data is updated in the NDR, the NDR will internally update

other linked data to maintain

internal consistency.

6 NDR maintains a single record for

each Person, which is maintained when the Person moves from one

state to another.

2.5. Decision Register

The following table summarises key Business Decisions that impact on the interface provided by the NDR:

# Decision Business Impact Approved By

Date

1 The NDR will support creation of a

Litter at the time of Service.

The NDR will support updating of a

Litter at the time of Whelping.

The NDR will support updating of a Litter at the time of Registration.

2 The authority which provides

notification of Service is the initial Owning Authority of a Litter.

Owning Authority of a Litter passes

`




Date

to the authority which provides

notification of Whelping (where this is different from the authority

which provided notification of

Service).

3 Earbrand is the primary business

identifier for a Dog.

If another identifier, e.g.

microchip, becomes the primary

identifier in future, this will necessitate modification to the

NDR and its interface.

4 Where multiple Sires are involved

in creating a Litter, separate Litter

records are created in the NDR for each Sire.

The following considerations apply

to State Body Systems (e.g. those

that are part of OzChase) that internally maintain a Service /

Litter record with multiple Sires:

When transferring data from

the State Body System to the

NDR, the State Body System

Litter record needs to be split into separate NDR Litter

records for each Sire. Given that the association between

pups and Sires is only established at the time of Litter

Registration, this implies that

multiple Sire Litters cannot be notified to the NDR prior to

Litter Registration.

When receiving data from the

NDR, the State Body System

may choose to merge

individual NDR Litter records into a single multiple Sire Litter

record. Any NDR Litter records that have the same Dam, the

same Service Date, but a different Sire, can be merged

into a single multiple Sire Litter

record.

5 The NDR will maintain Late Name

as part of the Dog Entity.

The NDR will record when a name is re-used.

GA is responsible for Dog naming,

including maintaining Late Name,

and managing re-use of names.

This information may be required

`




Date

by State Bodies in publishing Form

Guides.

6 The NDR will maintain a maximum of two microchips per dog.

This caters for the situation where a greyhound is re-chipped, when it

is not possible to locate the original microchip. Both microchips may

end up still being readable and are

therefore valid.

7 The NDR will maintain a “stud sire”

flag on a Dog.

Required by GA.

8 The NDR will maintain a history of the previous owners and the

previous trainers of a Dog.

9 As part of Race results, the NDR will maintain the Name, Owner and

Trainer of a Dog that was current at the time of the race.

This information is needed for the Stud Book.

10 Within Race results, “Position in

Running (PIR)” is a free text field.

There is no guarantee that State

Bodies will use this field in a consistent or compatible manner.

Rejected. See point 21

11 It is the responsibility of a State

Body to determine whether a Person already exists in the NDR

prior to creating a new Person Entity in the NDR.

State Bodies will need to adopt

appropriate matching procedures (e.g. using full name, date of birth,

etc) to determine whether an individual is already present in the

NDR.

12 The NDR needs to be able to maintain an “Authority to Breed”

on a Dam (with respect to Frozen Semen Service).

“Authority to Breed” is maintained by the State Bodies, but needs to

be available in the GA portal.

13 The NDR needs to be able to

maintain an “Authority to Bred” / “Stud Master” on a Sire.

14 Dogs will be automatically created

in the NDR when a Litter is registered.

State Bodies never need to create

a Dog in the NDR.

GA will still need to create Dogs in

the NDR, when Dogs are imported from overseas.

`




Date

15a A Penalty on a Person can only be

cleared by the authority that applied the penalty.

15b A Penalty on a Dog can be cleared

by any authority.

This enables a Satisfactory trial to

be performed in a state other than the one that applied the original

penalty.

16 The NDR will not provide a means of moving a Group from one

authority to another.

Note: this item is still under consideration, and may change if Business Rules can be defined describing the expected behaviour.

If a Group (e.g. a Syndicate) moves interstate, and wishes to be

recognised in the NDR in the new state, they need to create a new

registration for the Group in their

new state.

Rejected. See point 20

17 As part of Race results, the NDR

will record the time of each Dog.

18 Any authority may update the

following details of a Dog:

Microchip number(s)

Certificate number

Lifestate (e.g. racing / retired /

deceased)

These attributes will usually be

updated in the state where the greyhound is racing.

19 The NDR will only store persons

who are registered as Owners or Trainers.

Other categories of Person will

need to be maintained in the State Body Systems.

20 The NDR will allow a Group to

move from one authority to another.

A group will change authority

when the residential address of the manager of the group changes

state. E.g. SA to QLD.

21 Within Race results, “Position in Running (PIR)” is a string field

made up of numeric vales.

PIR can be recorded in a consistent form, regardless of how

states record other race comments such as speed and checks.

22 Within Race results, “Comments” is

a free text field.

There is no guarantee that State

Bodies will use this field in a consistent or compatible manner.

`




Date

23 Historical prize money other won

by a dog will not be migrated (where available) from the old

NDR to the new NDR.

Prize money other (breeder bonus,

trophy) in the existing NDR is incomplete and would provide an

incorrect prize money total.

24 Parameters for Data Migration from the old NDR to the new NDR

are as follows:

Dog – Whelped on or after 01

January 2000

Litter – Whelped on or after 01

January 2000

Person – Has an expiry date

greater than now or the

person is linked to any of the Dog/Litter records described

above

Meeting/Results – Meetings

held on or after 01 January 2005

Penalties – Current penalties

only

25 Margin for the first dog is the margin the dog beat the 2nd dog

by (or 3rd dog for a dead heat)

Provides richer race result information for the winning dog

26 Remove defined margin distances Actual margin distance can be

recorded without the need for

rounding the margin, thus increasing the accuracy of the

margin.

2.6. Items Known to be Incomplete

The following table summarises key items relating to the NDR which are known to be incomplete in the

current document.

# Issue Note

`



# Issue Note

1 The NDR will need to be backwards compatible to the existing CSV file based interface for a

period after go live.

RESOLVED – see section 7 on backwards

compatibility

The requirements for backward compatibility

are dependent on the cutover approach to the new NDR, which is yet to be finalised.

2 Parameters surrounding Data Migration to the

new NDR need to be agreed.

RESOLVED – see section 2.5, number 24

Some particular matters that need

consideration:

Which records will be migrated to the new NDR;

e.g.

Meeting entities will include meetings held

since a particular (to be agreed) date;

Litter entities will include Litters registered

since a particular (to be agreed) date;

Person entities will only include currently

registered persons.

The quality of the data migrated to the new

NDR is dependent on the quality of data in the existing NDR. There is limited scope for data

cleansing during the migration.

In some cases, data might be mandatory in the new NDR, but is not available in the current

NDR.

3 The clearing of a penalty where a dog has performed a satisfactory trailed in a state

different to the state that imposed the penalty

Can any state update a penalty even if they

didn’t impose the penalty

`



3. Business Overview

3.1. Business Context

The National Data Repository (NDR) is the master repository for greyhound data that is common between GA and the State Bodies.

The NDR also acts as a mechanism for GA and the State Bodies to publish data changes to other parties. Whenever GA or a State Body update locally held data, they may also choose to push any relevant

changes to the NDR. The NDR, in turn, publishes any such changes as events, which can then be picked up by other interested parties.

Figure 1 - Context Diagram

Figure 1 shows the interaction between the following systems:

The GA Web Portal is the GA system for maintaining greyhound data;

A State Body System is a state based system for maintaining greyhound data;

The National Data Repository (NDR).

`



3.2. Business Entities

The following table shows the Entities stored by the NDR, as well as a high-level summary of the data stored for each. (Section 4.1 provides a definitive listing of the Entities and Attributes held by the NDR.)

Entity Summary of Data Held in the NDR

Dog Identifying information

Ownership (current and historical)

Trainer (current and historical)

Penalties (current and historical)

Racing history

Litter Dam

Sire

Service date

Whelping date

List of dogs that resulted from the litter

Meeting Location

Date

List of Races, each including:

o Identifying information

o Prize money

o List of participating dogs

o Results

Person Identifying information

Contact details

Registered roles, e.g. owner, trainer

Group memberships

Penalties

Group Group type, e.g. Syndicate, Partnership

Group name

List of members

`



3.3. Business Operations

3.3.1. Operations

The interface supports the following high-level operations on each Entity:

Operation Description

Create Create a new instance of the Entity.

Update Modify an existing instance of the Entity.

Identify Perform a search against some specified search criteria.

Get Get the details of an instance of the Entity.

Publish NDR publishes details of an updated instance.

Note: It is not possible to Delete an Entity via the interface. If an Entity is no longer current, this is indicated by performing an Update either on a status field, or on a date field. For example, when a Dog

dies, the Dog Entity remains in the data store, but the status is updated to “Deceased”.

`



3.3.2. Sequence of Operations to Update and Publish Data

This section describes the sequence of operations involved, when a party makes use of the interface to

Update data, then the NDR Publishes the updated data to other interested parties.

The scenario is written in terms of an update that is entered by GA, and which is then published to the State Body Systems via the NDR. The reverse scenario, where the update originates in one of the State

Body Systems, may also occur.

Figure 2 – Update and Publish Data via NDR. Operations shown in blue correspond to NDR operations

listed in Section 3.3.1.

The sequence of steps shown in Figure 2 is as follows:

Step Description

1 A GA users logs into the GA system, and loads data for a specific Entity (e.g. a Dog)

into their web browser.

2 The GA user updates the Entity, and Submits.

3 The update is written to the GA data store.

`



Step Description

4 The GA system initiates an Update operation on the NDR.

5 The update is written to the NDR data store.

6 NDR Publishes an event, indicating that an update has occurred.

7 The State Body System polls the NDR to pick up the latest Events.

Polling is performed by performing a Get operation on all Events.

8 The State Body System determines that it is interested in the Event.

The State Body System performs a Get operation on the updated Entity.

9 The updated data is written to the State Body System data store.

GA, NDR and the State Body System are now synchronised.

Note that the sequence of events shown here is not intended to be prescriptive; clients are not required

to perform the listed operations in precisely the manner listed above.

`



4. Logical Interface

4.1. Logical Data Model

The Logical Data Model defines, and specifies the relationship between:

The Dog Entity;

The Litter Entity;

The Meeting Entity;

The Person Entity;

The Group Entity;

Events.

Note that Events are not Entities in their own right; the presence of an Event simply reflects a change to

one of the previously mentioned Entities: Dog, Litter, Meeting, Person or Group.

Most of the attributes specified in the Figure 3 - Figure 7 are considered to be self explanatory; however

for completeness, a description of each attribute is provided in Section 11.

`



4.1.1. Dog Entity

Figure 3 - Dog Entity. See footnote 1 for an explanation of the types and numbering used in this diagram.

**DIAGRAM TO BE UPDATED**

1 The types referred to in this, and later, diagrams are described in Section 1. The numbers in this, and later, diagrams are used to indicate which elements in the model are mandatory. A [1] indicates that an

`



The Dog Entity, shown in Figure 3, defines the attributes of a Dog.

A Dog is identified in the NDR by its earbrand.

The NDR stores a dog’s identifying information, as well as its current Owner, Trainer and Authority to

Breed (if applicable).

The NDR maintains a history of:

Ownership;

Trainer;

Penalties;

Races where the Dog has been a participant.

Other data maintained in the Dog Entity include a link to the Litter it was part of, and its “lifestate”.

element is mandatory; [0..1] indicates an element is optional. [0..*] indicates an element is optional, but if present, there may be many such elements.

`



4.1.2. Litter Entity

Figure 4 - Litter Entity


The Litter Entity, shown in Figure 4, defines the attributes of a Litter.

A Litter is identified in the NDR by a combination of dam earbrand, sire earbrand, and service date.

The Dam, Sire and service date are known at the time of Service. The Whelping Date and Litter Dogs (if

any), are known after Whelping has occurred. The earbrand and microchip no of each Litter Dog is known

once Litter registration has occurred.

Note that only one Sire is associated with each Litter. Where multiple Sires were involved in creating a

Litter, separate Litter records will be maintained for each Sire.

In order to maintain internal consistency between Litter and Dog entities, the NDR will automatically

create Dog entities in the NDR when a Litter is registered. The NDR will create a Dog Entity for every dog in the Litter, using the following attributes:

Attributes used to create Dog Entity Value

authority The authority who registers the Litter.

earbrand Taken from the Litter attributes for each individual Litter Dog.

color

sex

microchip no

`



Attributes used to create Dog Entity Value

whelping date Taken from Litter attributes.

lifestate Set to ”unnamed”.

stud sire flag Set to “false”.

This implies that a State authority should never need to create Dog entities directly in the NDR. The NDR will automatically create a Dog Entity for each registered pup.

`



4.1.3. Meeting Entity

Figure 5 - Meeting Entity


The Meeting Entity, shown in Figure 5, defines the attributes of a Meeting.

A Meeting is identified in the NDR by its Track Code, Date and Time Slot.

A Meeting consists of a number of Races. Each Race has some static data, such as Title, Grade and

Distance, which can be entered prior to the day of the race. The list of “Dogs in Race” is known once the

field is graded. “Result” and “Dog Race Result” are known after the race has concluded.

Note:

The “track code” field of Meeting is set when the Meeting Entity is created in the NDR. The “track

held” field of Meeting is used to record the code of the track where the meeting was actually held. “track held” will only differ from “track code” when there was a last minute change in the location of

the meeting.

the “name”, “owner name” and “trainer name” fields of Dogs in Race are used to preserve the

snapshot of information that was current at the time of the race.

In order to maintain the internal consistency of the NDR, when updating the results of a Meeting, the NDR

will automatically update the corresponding Races information maintained within the linked Dog Entity. Note that this update will occur even if the Owning Authority of the Meeting is not the Owning Authority

of the Dog.

`



4.1.4. Person Entity and Group Entity

Figure 6 – Person Entity and Group Entity


The Person Entity and the Group Entity, both shown in Figure 6, define the attributes of a Person and a

Group, and the relationship between them.

A Person or Group is identified in the NDR by their State (authority) and a state issued ID (state person id

/ state group id).

A Person may be registered as a Trainer or Owner, and these are maintained separately within

Registrations. A Group may be a Syndicate or a Partnership. Each Group consists of number of Members, one of whom is given the role of Manager.

Note that both Person and Group have an identifier assigned by their local authority (shown in Figure 6 as

“state person id” and “state group id”). Such identifiers are not guaranteed to be globally unique, so a Person or Group must always be identified by a combination of authority and identifier.

When a Person moves state, they are obliged (within a short period) to register with the authority in their new state. The authority in their new state will update their details in the NDR. This scenario is described

in more detail in Section 6.1.1.

As Person and Group are separate Entities within the NDR, they may be updated separately, which could in certain cases lead to inconsistencies. In order to maintain internal consistency, the NDR will perform

the following actions:

# Action initiated by a State Body System Action Performed by NDR to Maintain

Consistency

`



# Action initiated by a State Body System Action Performed by NDR to Maintain

Consistency

1 State Body System updates the Groups field of

a Person.

The Members field of the corresponding Groups

will also be updated by the NDR.

2 State Body System updates the Members field of a Group.

The Groups field of the corresponding Person will also be updated by the NDR.

`



4.1.5. Events

Figure 7 – Events

Figure 7 define the attributes of an Event File and an Event Entry. (Note that Events are not Entities in their own right; the presence of an Event simply reflects a change to one of the previously mentioned

Entities: Dog, Litter, Meeting, Person or Group.)

An Event File is identified in the NDR by its date, and has a timestamp showing the time of last update.

Time will be UTC time (TBC).

Each Event Entry includes both the Owning Authority (of the created or updated Entity), and the authority

which requested the modification of the data. The Owning Authority will be different from the Previous

Owning Authority in cases where the event resulted in a change of Owning Authority.

In addition, each Entry has:

The type of event;

The name of the Entity to which the event occurred, e.g. the name of the Dog;

A link to the underlying Entity.

`



4.2. Data Ownership

4.2.1. Owning Authority

The following Business Rules arise from the principle that all data stored in the NDR has an Owning

Authority.

# Business Rule Business Impact

1 Ownership is defined at the Entity level.

2 Each Entity has an Attribute named “authority” which stores its Owning Authority.

3 When an Authority requests creation of an

Entity, they become the Owning Authority of the Entity created within NDR.

4 For the following Entities, the Owning

Authority never changes after creation:

Dog

Meeting

5 The Owning Authority can change for a Litter

Entity when Whelping has occurred.

The authority that lodges the notification of

Whelping will become the Owning Authority of the Litter Entity.

6 The Owning Authority can change for a

Person Entity, when that Person physically moves and registers with a new authority.

The authority which wishes to claim

ownership will need to make a request to the NDR via the interface.

4.2.2. Ability to Modify Data Held by the NDR

The following Business Rules govern the ability to modify data held by the NDR:


1 Except as stated under rules 3 to 8 below:

The Owning Authority can modify any aspect of an Entity.

2 Except as stated under rules 3 to 8 below:

Any authority which is not the Owning

Authority cannot modify any aspect of an

Entity.

`




3 GA is the only authority permitted to modify the following fields of the Dog Entity:

Naming (including Late Name and name

re-use)

DNA no

Stud Sire flag

4 Any authority can add a new record to the following fields of any Dog Entity:

Penalty

5 Any authority can update the following fields of any Dog Entity:

Lifestate

Microchip no(s)

Certificate no

Owner

Trainer

Penalty

6 Any authority can notify the NDR that

Whelping has occurred.

The authority that lodges the notification of

Whelping will become the Owning Authority of the Litter Entity.

7 Any authority can add a new record to the

following fields of any Person Entity:

Penalty

8 Only the authority that originally applied a

Penalty to a Person Entity can clear that

Penalty.

`



4.3. Logical Events

The following table describes the Logical Events (i.e. occurrences that cause a change in the state of the NDR) and the resulting action:

Event Description Resulting Action

Entity

Created

The NDR receives a request to create a

new Entity.

The new Entity is created within the NDR.

An Event is Published notifying other

parties of the new Entity.

Entity

Update

The NDR receives a request to update an

existing Entity.

The Entity is updated within the NDR.

An Event is Published notifying other

parties of the update.

`



5. Physical Interface

5.1. Web Services

The following points apply to the tables included in Sections 5.1.1-5.1.6.

The “Permitted Authority” column lists the authorities who are permitted to make the request. If any authority makes a request they are not permitted to

make, they will receive an “Unauthorised” error (see Section 5.7 for a full list of error responses).

The “Input” column refers to various Entities and Components; these are defined via the schemas included in Sections 5.5.1 and 5.5.2.

`



5.1.1. Dog API

Business Operation (per

Section 3.3.1)

Permitted Authority

Entity is Identified by

HTTP Method URL Input Success Response

Error Condition

Error Response

Create GA earbrand POST /dog/<earbrand>

A Dog Entity The URL for the new Dog Entity.

(None – if earbrand not found, a new dog created)

Update Owning Authority earbrand POST /dog/<earbrand

>

A Dog Entity The URL for the

updated Dog Entity.

(None – if earbrand not found, a new dog created)

Update (earbrand)

Owning Authority earbrand POST /dog/<earbrand>/earbrand

(where <earbrand> is

the old earbrand)

Earbrand component

(containing the new earbrand)

The URL for the updated Dog

Entity.

Dog does not exist

Item not found error

Update (name) GA earbrand POST /dog/<earbrand

>/name

Name

component

The URL for the

updated Dog

Entity.

Dog does not

exist


Update (dna) GA earbrand POST /dog/<earbrand>/dna

Dna component The URL for the updated Dog

Dog does not exist

`



Business

Operation (per Section 3.3.1)

Permitted

Authority

Entity is

Identified by

HTTP Method URL Input Success

Response

Error Condition

Error Response

Entity. Item not found

error

Update

(studsire)

GA earbrand POST /dog/<earbrand

>/studsire

Studsire

component

The URL for the

updated Dog

Entity.

Dog does not

exist


Update (lifestate)

Any earbrand POST /dog/<earbrand>/lifestate

Lifestate component

The URL for the updated Dog

Entity.

Dog does not exist


Update

(microchip)

Any earbrand POST /dog/<earbrand

>/microchip

Microchip

component

The URL for the

updated Dog Entity.

Dog does not

exist

Item not found

error

Update

(certificate)


>/certificate

Certificate

component

The URL for the

updated Dog

Entity.

Dog does not

exist


Update Any earbrand POST /dog/<earbrand Owner The URL for the updated Dog

Dog does not

`



Business


Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

(owner) >/owner component Entity. exist


Update

(trainer)


>/trainer

Trainer

component (to add a new

trainer)

Or

Leave the body of the HTTP

request empty

(to remove the current trainer,

without assigning a new trainer)

The URL for the

updated Dog Entity.

Dog does not

exist

Item not found

error

Update

(penalty) – add a new penalty


>/penalty

Penalty

component

The URL for the

updated Dog Entity.

Dog does not

exist

Item not found

error

Update

(penalty) – modify an

Any earbrand

penalty code

POST /dog/<earbrand

>/penalty

Penalty

component

The URL for the

updated Dog

Dog does not

exist

`



Business


Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

existing

penalty

penalty

commencement date

Entity. Item not found

error

Get (entity) Any earbrand GET /dog/<earbrand>

- The matching Dog Entity.

Dog does not exist


Get (metadata)

Any earbrand GET /dog/<earbrand>/meta

- The metadata for the matching

Dog Entity.

Dog does not exist

Item not found

error

`



5.1.2. Litter API


Section 3.3.1)

Permitted Authority



Error Condition

Error Response

Create Any Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earbrand>/<dam_ear

brand>/<service

_date>

A Litter Entity The URL for the new Litter Entity.

State / Dam does not exist

Item not found

error

Update Owning Authority Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earb

rand>/<dam_earbrand>/<service

_date>

A Litter Entity The URL for the

updated Litter Entity.

State / Dam

does not exist

Item not found

error

Update (whelping)

Any Sire earbrand

Dam earbrand

Service date

POST /litter/<sire_earbrand>/<dam_ear

brand>/<service_date>/whelping

Whelping component

The URL for the updated Litter

Entity.

State / Dam does not exist


Get (entity) Any Sire earbrand

Dam earbrand

Service date

GET /litter/<sire_earb

rand>/<dam_ear

brand>/<service_date>

- The matching

Litter Entity.

Litter does not

exist


`



Business


Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

Get

(metadata)

Sire earbrand

Dam earbrand

Service date

GET /litter/<sire_earb

rand>/<dam_earbrand>/<service

_date>/meta

- Metadata for the

matching Litter Entity.

Litter does not

exist


`



5.1.3. Meeting API

Note: In the following table, the Meeting Time Slot is one of “M” (morning), “D” (day), “T” (twilight), “N” (night).

Business

Operation (per

Section 3.3.1)

Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

Create Any Track code

Meeting date

Meeting time slot

POST /meeting/<track

_code>/<date>/

<time_slot>

A Meeting Entity The URL for the

new Meeting

Entity.

Track doesn’t

exist

Item not found error.

Update Owning Authority Track code

Meeting date

Meeting time slot

POST /meeting/<track_code>/<date>/

<time_slot>

A Meeting Entity The URL for the new/updated

Meeting Entity.

Track doesn’t exist

Item not found

error.

Get (entity) Any Track code

Meeting date

Meeting time slot

GET /meeting/<track_code>/<date>/

<time_slot>

- The matching Meeting Entity.

No meeting found

Item not found error.

Get

(metadata)

Track code

Meeting date

Meeting time slot

GET /meeting/<track

_code>/<date>/<time_slot>/met

a

- Metadata for the

matching Meeting Entity.

Meeting does

not exist

Item not found

error

`



`



5.1.4. Person API


Section 3.3.1)

Permitted Authority



Error Condition

Error Response

Create Any State

State person id

POST /person/<state>/<state_person_id

>

A Person Entity The URL for the new Person

Entity.

State does not exist

Item not found

error

Update Owning Authority State

State person id

POST /person/<state>/

<state_person_id >

A Person Entity The URL for the

updated Person Entity.

State does not

exist

Item not found

error

Update (Owning

Authority) – i.e. when the Person

has moved state

The authority of the state to

which the Person has moved

State

State person id

(of the old state)


>/move

(the state and id

of the old state)

A Person Owning Authority

component

(the body of the

input includes the new

authority and id)

The URL for the updated Person

Entity (i.e. in the new state)



Update (penalty) – add

a new penalty

Any State

State person id


>/penalty

A Person penalty component

The URL for the updated Person

Entity.



`



Business


Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

Update

(penalty) – modify an

existing

penalty

The Authority

who applied the Penalty.

State

State person id

Penalty code

Penalty

commencement date

POST /person/<state>/

<state_person_id >/penalty

A Person penalty

component

The URL for the

updated Person Entity.

State does not

exist

Item not found

error

Get (entity) Any State

State person id

GET /person/<state>/

<state_person_id>

- The matching

Person Entity.

No matching

person

Item not found

error.

Get (entity) –

when the Person has moved state

Any State

State person id

(of the old state)

GET /person/<state>/

<state_person_id>

- The URL for the

updated Person Entity (i.e. in the

new state)

No matching

person

Item not found

error.

Get (metadata)

Any State

State person id

GET /person/<state >/<person_state

_id>/meta

- Metadata for the matching Person

Entity.

State / Person Id does not

exist

`



Business


Permitted

Authority

Entity is

Identified by


Response

Error Condition

Error Response

Item not found

error

`



5.1.5. Group API


Section 3.3.1)

Permitted Authority



Error Condition

Error Response

Create Any State

State group id

POST /group/<state>/<state_group_id

>

A Group Entity The URL for the new Group

Entity.


Item not found

error

Update Owning Authority State

State group id

POST /group/<state>/

<state_group_id>

A Group Entity The URL for the

updated Group Entity.

State does not

exist

Item not found

error

Get (entity) Any State

State group id

GET /group/<state>/

<state_group_id>

- The matching

Group Entity.

No matching

group

Item not found

error.

Get

(metadata)

Any State

State group id

GET /group/<state

>/<state_group_

id>/meta

- Metadata for the

matching Group

Entity.

State / Group

Id does not

exist

Item not found

error

`



`



5.1.6. Events API


Section 3.3.1)

Permitted Authority



Error Condition

Error Response

Get (events) Any - GET /events/<date> - Atom feed of events for the

specified date.

No events found

Atom feed is

empty.

`



5.2. Encryption

Each HTTP request is encrypted via SSL.

5.3. Authentication

Each authority will be issued with a unique key <apikey> which must be included with each HTTP

request.

Two methods are supported for doing this:

# Method Details Example

1 Query

String

The key can be appended to the HTTP request

as follows:

<HTTP method> <URL>?authority=<apikey>

Where

<HTTP method> is either “GET” or “POST”

<URL> is as shown in the “URL” column of

the tables included in Section 5.1

<apikey> is the unique API key.

GET /dog/abc123?authority=562AFA

Host: ndr.galtd.org.au

…

2 HTTP

Header

The key can also be included in the HTTP

header, on a distinct line of the form:

“Authority: <apikey>”

Where

<apikey> is the unique API key.

GET /dog/abc123

Host: ndr.galtd.org.au

Authority: 562AFA

…

The means of distributing the key is yet to be determined. Each authority is responsible for maintaining

the security of the issued key. The key will be changed on request.

`



5.4. Change Detection

The HTTP Entity Tag (ETag) is used to identify a particular version of an Entity within the NDR.

The standard usage of ETags in relation to GET and POST methods is as follows:

Method Request If the NDR holds a later

version of the Entity

than the client making the request …

If NDR does not hold a

later version of the

Entity than the client making the request …

GET Header includes a line of the

form:

“If-None-Matches: <ETag>”

where <ETag> corresponds to the version of the Entity

held by the client.

NDR returns the requested

Entity.

The header of the response

includes a line of the form:

“ETag: <ETag>”

where <ETag> corresponds

to the requested Entity.

NDR returns a response

with Status Code “304 Not Modified”.

The body of the response is empty.

POST Header includes a line of the

form:

“If-Match: <ETag>”

where <ETag> corresponds

to the version of the Entity held by the client.

NDR does not accept the

update.

NDR returns an error

response with Status Code

“412 Precondition Failed”.

NDR accepts the update.

The header of the response includes a line of the form:

“ETag: <ETag>”

where <ETag> corresponds to the updated Entity.

Further detail, including more details of the request and the response, is laid out in Section 10.

`



5.5. Schemas

5.5.1. Entities

Entity Schema (returned by

GET operation)

Schema (used to

Create or Update

Entity)

Dog dog.xsd dog_in.xsd

Litter litter.xsd litter_in.xsd

Meeting meeting.xsd meeting_in.xsd

Person person.xsd person_in.xsd

Group group.xsd group_in.xsd

Note that two schemas are provided for each Entity:

Schema (returned by GET operation): This is the full schema, that specifies the Entity returned by a

GET method;

Schema (used to Create or Update Entity): This is the schema used by the Owning Authority to Create

or Update an Entity. The following attributes (which are present in the full schema) are omitted from this schema:

o authority: always omitted, as this is implied by which ever authority calls the method;

o any elements already present in the URL are also omitted (to avoid duplication); e.g.

earbrand is omitted from Dog.

o Dog: name, dna, studsire are omitted, as these can only be set by GA.

`



5.5.2. Components

Business Operation

(refer Section 5.1)

Component

Dog – Earbrand Update (earbrand) dog_earbrand.xsd

Dog – Name Update (name) dog_name.xsd

Dog – Dna Update (dna) dog_dna.xsd

Dog – Studsire Update (studsire) dog_studsire.xsd

Dog – Lifestate Update (lifestate) dog_lifestate.xsd

Dog – Microchip Update (microchip) dog_microchip.xsd

Dog – Certificate Update (certificate) dog_certificate.xsd

Dog – Owner Update (owner) owner.xsd

Dog – Trainer Update (trainer) trainer.xsd

Dog – Penalty Update (penalty) dog_penalty.xsd

Litter – Whelping Update (whelping) litter_whelping.xsd

Person – Owning

Authority

Update (Owning Authority) person_owningauthority.xsd

Person – Penalty Update (penalty) person_penalty.xsd

`



5.5.3. Events

The following schemas define the XML component that is returned from one of the Get (Events)

operations. In each case, the returned component is an Atom feed (defined by atom.xsd), extended in accordance with an element of type Event Details Type (defined within the schema types.xsd).

Entity Business Operation (ref

Section 5.1)

Schema

All Get (events) atom.xsd

Note that the NDR will only populate a small subset of the attributes defined in the Atom feed. The list of attributes to be populated is as follows:

`



Element Defined in Schema Attribute Meaning

feed atom.xsd updated The time stamp on the Feed.

title The title of the Feed, e.g. “NDR Events”.

subtitle The subtitle of the Feed, e.g. “Ndr Events

for 2012-01-30”

id The unique identifier of the feed.

link The link to the Events file.

entry types.xsd

(within eventDetailsType)

owning authority The Owning Authority of the Entity after

the event has occurred.

previous authority The Owning Authority of the Entity before

the event has occurred (this will only differ

from the “owning authority” if the Owning Authority has changed).

transaction authority

The authority that made the request that gave rise to the event.

name The human readable name of the Entity on

which the event occurred; e.g. the full name of a Person.

etag The etag corresponding to the updated

Entity.

eventType The type of event.

atom.xsd description A free text description of the event.

5.5.4. Metadata

Metadata refers to the data associated with each record in the NDR, such as ownership, relative links and

versions. This data can be read, but cannot be written, by clients.

The following schema defines the XML component that is returned from one of the Get (metadata)

operations.

`



Entity Business

Operation (ref Section 5.1)

Schema

All Get (metadata) meta.xsd

Note that the information contained within an Events file and the Metadata is essentially the same. It is

just that the Events file contains all updates for a given date, whereas Metadata contains all updates for a given Entity.

5.5.5. Type Definitions

The following schema defines types used in the previously listed schemas.

Schema

Types types.xsd

`



5.6. Validation

The following validation is performed on each request:

Request Validation Test Performed

Any Authentication Has the user provided a valid API key, in accordance with

Section 5.2?

Any Integrity of URL Is the URL correctly formed?

POST Structural Integrity Does the body of the request conform to the relevant XSD?

POST Write Permissions Is the authority permitted to make the request, as defined in Section 4.2.2?

POST Update is not based on stale data

Does the ETag included in the POST request correspond to the latest version of the Entity that is being updated?

`



5.7. Status Codes

The response to each HTTP request will include a standard HTTP Status Code, as per the following tables:

5.7.1. Valid Requests

Request Success Scenario HTTP Status Code

GET The data corresponding to an Entity is read from the

NDR.

200 OK

POST A new Entity is created in the NDR. 201 Created

GET There is no update since the previous GET. 304 Not Modified

GET The requested resource does not exist.

(Note: This is still considered a valid request.)

404 Not Found

GET (Dog) The Dog earbrand has changed.


301 Moved Permanently

GET (Person)

The Person has moved state.


301 Moved Permanently

`



5.7.2. Invalid Requests

The following error scenarios correspond to failure of the validation outlined in Section 5.6.

Request Validation Error Scenario HTTP Status Code

Any Authentication Invalid credentials. 401 Unauthorized

Any Integrity of URL The URL is malformed. 404 Not Found

POST Structural Integrity The body of the request is

malformed (i.e. it does not conform to the XSD).

400 Bad Request

POST Write Permissions The request attempts to

modify read-only data.

401 Unauthorized

POST Update is not based on

stale data

The ETag included in the

POST request does not correspond to the version

of the Entity held by the

NDR.

412 Precondition Failed

`



6. End to End Scenarios

This section describes some key end to end scenarios which make use of the NDR interface.

6.1. Success Scenarios

6.1.1. End to End Process for Assigning / Updating a Dog Name

The following diagram and table defines the sequence of events involved in assigning or updating the name of a greyhound.

Figure 8 – Sequence of Events in Naming a Greyhound. The steps highlighted in blue impact the NDR.

Step Description Call to NDR Comment

1 An individual lodges a naming

application through their State Body.

(none) This process by which this

occurs may vary from state to state.

2 The State Body validates the

request.

(none) This process by which this

occurs may vary from state to state.

3 The State Body lodges the

naming application with GA via the Naming Application

interface.

(none) The Naming Application

interface is supported by the GA Web Portal, rather than by

the NDR. It is not defined in the current document.

`



Step Description Call to NDR Comment

4 GA applies business rules to determine which, if any of the

requested names are assigned to the greyhound.

(none) GA may, at its discretion, assign a name other than one

of the requested names.

5 If a name is assigned, the new

name is pushed from GA into the NDR.

Dog – Update (Name)

6 The State Body receives

updates from the NDR.

Get (Events)

6.1.2. Registered Person Moves Interstate

The following table summarises the changes to the NDR when a registered person moves interstate:

Timing Business Event Data Known Call to NDR Comments

Person moves

interstate

(none) (none) (none) Person remains

registered with their old State

Body.

Within 3 months Person registers with new State Body, and

is assigned a new

state person id.

Old state body

Old state person id

New state body

New state person id

The new state body posts a

Person - Update

call to the old URL (i.e. the URL

defined by the old state body /

old state person id).

The response

from the NDR contains the URL

of their new registration (i.e.

the new state

body / new state person id).

The NDR will from this point on

automatically

redirect requests to the old URL to

the new URL.

* People moving

between states that use the

OzChase system

will retain their OzChase ID.

However the owning authority

will change to the

new state.

6.1.3. Expected Updates of the Litter Record

The following table summarises the expected updates to the NDR at Service, Whelping and Registration of

a Litter:

`



Timing Business Event Data Known Call to NDR Comments

Service Service Dam

Sire

Service Date

Litter – Create

Whelping Whelping As for Service, plus:

Whelping Date

Pups, for each:

Colour

Sex

Litter – Update

Whelping + 12

weeks (typically)

Registration As for Whelping,

plus:

Earbrand

Microchip No

Litter - Update The NDR will

automatically create Dog entities

for each Dog in the litter at this point.

6.2. Failure Scenarios

This section describes some key high-level failure scenarios, and provides guidance on best practice on

the client side to avoid the scenario.

In each of these cases, the “local system” is any consumer of the GA interface; e.g. could be the GA Web

Portal, or it could be a State Body System.

Scenario Description What NDR Will Do … Best Practice on

Client Side …

Local System Unable to Push Update to

NDR

The local system

has applied an update to its local

data store.

The local system

tries to push change

to NDR, but fails

e.g. due to network failure.

Nothing; the NDR is

not aware of the attempted update.

Retry, e.g.

overnight.

If the retry also

fails, log a

notification according to a

suitable (local)

mechanism – e.g. write to an error

log.

Once connectivity is

restored, the local

system will have to

re-POST the update

`



Scenario Description What NDR Will Do … Best Practice on

Client Side …

(possibly with

manual intervention by local system

admin).

Local System Attempts to Push and

Update to NDR

Without Sufficient Privileges

The local system

has write privileges to certain fields, but

tries to update other

fields.

NDR responds with

“invalid” request, as per Section 5.7.2.

Local system should

ensure such data is “read only”, so the

local operator does

not inadvertently edit such data.

If multiple POST

transactions are available (e.g. to

Dog Entity) then the local system should

use the most

appropriate POST – e.g use Update

(owner) rather than Update on the entire

Dog Entity.

Client Attempts an Update Based on

Stale Data

The local system

attempts to update the NDR based on

stale data (i.e. without having first

picked up previous

changes).

NDR responds with

“invalid” request, as per Section 5.7.2.

Local system should

perform a GET just prior to allowing a

user to modify data.

Note that this will

minimise the chance

of collision; however

collision is still possible.

Update Missed by

Local System

Local system was

down when update

was published.

Nothing; the NDR is

not aware this has

occurred.

Local system should

regularly poll the

NDR to ensure if picks up all changes.

Local system should

perform a GET just prior to allowing a

user to modify data.

Local system should

maintain a log of

which events have

been processed.

`



7. Backwards Compatibility

This section describes the backwards compatibility supported by the NDR. The NDR will be populated

with data received from the existing CSV files as defined in the “Technical Specification Document – National Data Repository Revision 03” document dated 17th November 2008.

7.1. Operation

The NDR will provide “one way” backwards compatibility. This means the NDR will be populated with

data received from the existing CSV files supplied by state bodies. To receive data from the NDR, state bodies will need to ensure their systems support the reading of published events from the NDR as defined

in this document.

7.2. Existing NDR files

The following is a list of the current files that will be supported by the NDR (all files are to be supplied in CSV format)

1. RF – Race Fields

2. RR – Race Results 3. DD – Dog Details

4. PR – Person Registration 5. LD – Litter Details

To ensure the correct operation of the NDR, the following sections outline the critical pieces of data that

must be supplied for each of the existing file types. The items listed in the next section are already supplied according to the current NDR specification, therefore the next section is a reminder of how the

data is to be supplied.

The only additional piece of data is in the PR – Person Registration file and the GM (Group member)

record. In this record the state (code) must be supplied (currently optional). The state code will identify the group member as not being from the state sending the PR file and will therefore take the NrdId in the

GM record to link the group to the group member in the NDR.

7.2.1. RF – Race Fields

To support backwards compatibility for this file, the following must be observed:

1. TrainerState must be supplied 2. StateTrainerID must be supplied where the trainer is from the state uploading the RF file

3. NdrId(Trainer) must be supplied where the trainer is NOT from the state uploading the RF file. This needs to be the full NDR entity ID e.g. /person/WA/12345

All other existing rules for the RF file will apply.

`



7.2.2. RR – Race Results

Existing rules for the RR file will apply.

7.2.3. DD – Dog Details


1. DS Record – Existing rules for the DS record will apply

2. DT Record a. StateTrainerID must be supplied where the trainer is from the state uploading the

DD file b. NdrID (trainer) must be supplied where the trainer is NOT from the state uploading

the DD file. This needs to be the full NDR entity ID e.g. /person/WA/12345 c. All other existing rules for the DT record will apply

3. DO Record

a. NdriD (owner) must be supplied. This needs to be the full NDR entity ID e.g. /person/WA/12345 or /group/WA/3214 for dogs owned by a group

b. All other existing rules for the DO record will apply 4. DP Record – Existing rules for the DP record will apply

7.2.4. PR – Person Registrations


1. PI – Person Individual

a. State must be supplied

b. PersonID must be supplied where the state is the same as the state uploading the PR file

c. All other existing rules for the PI record will apply 2. PG – Person Group

a. State must be supplied

b. PersonID must be supplied where the state is the same as the state uploading the PR file

c. All other existing rules for the PG record will apply 3. GM Group Member

a. State must be supplied b. PersonID must be supplied where the state is the same as the state uploading

the PR file

c. NdrId must be supplied where the state is NOT the same as the state uploading the PR file. This needs to be the full NDR entity ID e.g. /person/WA/12345

d. All other existing rules for the GM record will apply

7.2.5. LD – Litter Detail


`



1. NDrId must be supplied. This needs to be the full NDR entity ID e.g. /person/WA/12345 or /group/WA/3214 for breeders that are a group

2. All other existing rules for the LD file will apply

`



8. Definitions, Acronyms and Abbreviations

Term Meaning

API Application Programming Interface.

CSV Comma Separated Values.

Dam A female greyhound that is registered for breeding.

DNA Number An encrypted set of numbers that reflect a greyhound’s DNA makeup. It is used for unique identification of the greyhound, and for determining its pedigree.

ETag HTTP Entity Tag.

GA Greyhounds Australasia.

GRV Greyhound Racing Victoria. The body that administers greyhound racing in Victoria.

HTTP Hyper Text Transfer Protocol.

IDA Interface Dependency Agreement.

Late Name The previous name of a Dog, which has been renamed due to an explicit renaming request.

Litter The dogs born at the same time to a single Dam.

Markings The markings of a dog, such as colour, patterns, toe colours etc that are used to identify a dog.

NDR National Data Repository. A common data store used by all State Bodies for the

exchange of information relating to greyhounds, registered people, race form, race results and litters.

Owner A person who is registered to own a racing greyhound and has responsibility for the welfare of the greyhound.

PIR Position in Running

Service The natural or artificial joining together of a Sire’s semen with a Dam.

Sire A male greyhound that is registered for breeding.

SSL Secure Socket Layer

State Body A body that administers greyhound racing in an Australian state or territory, or in New Zealand.

Stud Book A book that records the official registration of all stud and breeding activity for a

greyhound association in a particular year.

Trainer A person who is registered to train, kennel, nominate and race a greyhound.

URL Universal Resource Locator.

XML eXtensible Markup Language.

XSD XML Schema Definition.

`



9. Reference Documents

Ref Name

Version

Date

Version Date Link

1 Business Requirements

Document

0.1 April 2011 http://grvwiki.onconfluence.com/download/attachments/2032710/GA+Business+Requirements+Docum

ent.docx

2 Functional Solution

Document

0.6 June 2011 http://grvwiki.onconfluence.com/download/attachments/2032714/GA+-

+Functional+Solution+Document+v0.5.docx

3 Architecture

Design

1.0 May 2011 http://grvwiki.onconfluence.com/download/attachm

ents/2032712/GA+Portal+and+NDR+Architecture+Design+v1.0.docx

4 Minutes of User

Group Workshop, 20

July 2011

July 2011

USER_GROUP_WORKSHOP_NOTES_27072011.doc

http://grvwiki.onconfluence.com/download/attachments/2032710/GA+Business+Requirements+Document.docx



http://grvwiki.onconfluence.com/download/attachments/2032714/GA+-+Functional+Solution+Document+v0.5.docx



http://grvwiki.onconfluence.com/download/attachments/2032712/GA+Portal+and+NDR+Architecture+Design+v1.0.docx



`



10. Appendix: Use of ETags

The following tables provide further detail of the use of ETags, as introduced in Section 5.4.

Method Condition Result Request Response

Header Body Status Code

Header Body

GET If ETag

included in request

AND ETag is up-to-

date.

No Entity

is returned,

as client is already

up-to-

date.

Includes a

line of the form:

“If-None-Matches:

<ETag>”

where <ETag> is

up-to-date.

Empty 304 Not

Modified

(Does not

include ETag)

Empty

GET ETag not

included in request

Latest

Entity is returned.

(Does not

include ETag)

Empty 200 OK

Includes

the ETag, in a line of

the form:

“ETag:

<ETag>”

The

requested Entity

GET ETag is included in

request,

but is not up-to-date

Latest Entity is

returned.

Includes a line of the

form:

“If-None-Matches:

<ETag>”

where

<ETag> is

NOT up-to-date.

Empty 200 OK

Includes the ETag,

in a line of

the form:

“ETag:

<ETag>”

The requested

Entity

`



Method Condition Result Request Response

Header Body Status Code

Header Body

POST If ETag

included in request

AND ETag is up-to-

date.

NDR

accepts updated

Entity.

Includes a

line of the form:

“If-Match: <ETag>”

where

<ETag> is up-to-

date.

An Entity 201

Created

Includes a

new ETag, correspond

ing to the updated

Entity, in a

line of the form:

“ETag: <ETag>”

Empty

POST ETag not

included in request

NDR

rejects updated

Entity, as the client

did not

specify the latest

ETag.

(Does not

include ETag)

An Entity 412

Precondition Failed

(Does not

include ETag)

Empty

POST ETag is

included in

request, but is not

up-to-date

NDR

rejects

updated Entity, as

the client was not

up-to-

date.

Includes a

line of the

form:

“If-Match:

<ETag>”

where

<ETag> is

NOT up-to-date.

An Entity 412

Preconditio

n Failed

(Does not

include

ETag)

Empty

`



11. Appendix: Description of Attributes

The following tables provide a general description of the attributes of the Entities described in Section 4.1.

Note that the precise definition of each attribute, including the full list of permissible values, is provided in

the relevant schema (included in Section 5.5).

11.1. Attributes of Dogs

Entity

Dog

Attribute Sub Attribute Description

Authority The Owning Authority of the dog.

Earbrand The earbrand of the dog.

Name The current name of the dog.

Late name The previous name of the dog (set when the dog is

renamed).

Name reused from This date is set if another dog has been assigned the dog’s name. This can occur once the dog is e.g.

more than 15 years old. In some State Body

Systems, the dog’s name may be displayed with the suffix “(OLD)” to reflect the fact that the name has

been re-used.

Color The markings of the dog.

Sex The sex of the dog.

Microchip 1 The primary microchip of the dog.

Microchip 2 The secondary microchip of the dog.

Whelped date The date when the dog was whelped.

Certificate no The certificate number of the dog.

Cleared to race date The date the dog was first cleared to race.

Registration date The date the dog was first registered.

Dna no The DNA signature of the dog.

Lifestate Indicates whether the dog is active, racing, retired or deceased.

Stud Sire Flag Indicates whether the dog is a stud sire.

Owner

Name The name of the owner of the dog.

From date The date that the owner commenced owning the dog.

`



Entity

Dog


Trainer

Name The name of the trainer of the dog.

From date The date that the trainer commenced training the dog.

Previous Owner

Name The name of the owner of the dog.

From date The date that the owner commenced owning the dog.

To date The date that the owner ceased owning the dog.

Previous Trainer

Name The name of the trainer of the dog.

From date The date that the trainer commenced training the dog.

To date The date that the owner ceased training the dog.

Authority to Breed

Name The name of the individual who has been given

authority to breed the dog.

From date The date that the authority to breed was granted.

Penalty

Authority The authority which applied the penalty.

Code The code that specifies the penalty.

Commencement date The date the penalty commences.

Expiration date The date the penalty expires. This will be populated if the penalty is a fixed number of days, commencing at the commencement date and

expiring at the expiration date.

Trial required Indicates whether a trial is required to clear the

penalty, and specifies which track the trial must be performed it.

Penalty clearance Provides details relating to the clearance of the penalty, including the authority which cleared the penalty, the date, and the result of satisfactory trial

(if a satisfactory trial was required).

Race

Race no The race number.

Race title The race title.

`



Entity

Dog


Track The track where the race was held.

Date The date of the race.

Distance The distance of the race.

11.2. Attributes of Litters

Entity

Litter


Authority The Owning Authority of the Litter.

Dam earbrand The earbrand of the dam.

Sire earbrand The earbrand of the sire.

Service date The date on which service occurred.

Whelping date The date whelping occurred.

Service status Indicates whether the service is active, missed, whelped.

Service method Indicates whether the service is natural or FSI.

FSI details Includes details of FSI, including the name of the

inseminator, the name of the facility, and the Breeding Unit IDs.

Breeder

Name The name of the breeder of the litter.

Litter Dog

Color The markings of the dog.

Sex The sex of the dog.

Earbrand The earbrand of the dog.

Microchip The primary microchip of the dog.

`



11.3. Attributes of Meetings

Entity

Meeting


Authority The Owning Authority of the meeting.

Track code Indicates the track where the meeting was scheduled.

Date The date of the meeting.

Time slot The time slot of the meeting (Morning / Day /

Twilight / Night).

Meeting cancelled Set to true if the meeting was cancelled.

Track held The track where the meeting was actually held.

Meeting type The type of meeting, e.g. TAB, non-TAB.

Race

Race no The number of the race.

Race abandoned Set to true if the meeting commenced, but this

particular race was abandoned.

Race title The title of the race.

Event type A free text field providing further detail of the type of event.

Grade The grade of the race.

Distance The distance of the race.

Start time The start time of the race. Note that this specifices both the time and time zone. All times are to be

submitted in local time. Other states reading this time can convert as necessary.

Prize1 – Prize8 The prize money awarded for positions 1-8 in the race.

Prize other Additional prize money that may be allocated for a race event (e.g. GOBIS prize money).

Prize code Indicates the reason for the additional prize money.

Result The winning time, and the times recorded at each of

the splits and the rug number of the first dog at each split

`



The following table describes the sub sub attributes of Dogs in Race (refer Figure 5):

Entity

Meeting – continued

Sub Sub Attribute Sub Sub Sub

Attribute

Description

Name The name of the dog.

Owner name The name of the owner of the dog (i.e. at the time of the race).

Trainer name The name of the trainer of the dog (i.e. at the time

of the race).

Dog grade The grade of the dog (i.e. at the time of the race).

Rug no The rug worn by the dog.

Dog Result (Non Starter)

Result Why the dog didn’t start

Dog Other Result (Non finisher)

Box No The number of the box where the dog started the race.

Weight The weight of the dog.

Start price The starting price of the dog.

PIR The Position in Running of the dog at each of the

position markers.

Comments This is a free text field, and different states may choose to populate this field using differing

conventions.

Result Why the dog didn’t finish

Dog Race Result

(Finished)

Box no The number of the box where the dog started the race.

Place The place achieved by the dog in the race.

Time The time achieved by the dog in the race.

Weight The weight of the dog.

Margin The margin of the dog with respect to the winner. This implies that the margin of the lead dog is

always 0.

Start price The starting price of the dog.

`



Entity

Meeting – continued

Sub Sub Attribute Sub Sub Sub

Attribute

Description

PIR The Position in Running of the dog at each of the

position markers.

Comments This is a free text field, and different states may choose to populate this field using differing

conventions.

`



11.4. Attributes of Persons

Entity

Person


Authority The Owning Authority of the person.

State person id The identifier of the person, as assigned by the Owning Authority.

Full name The full name of the person.

Address The address of the person.

Date of birth The date of birth of the person.

Registry expiry date The expiry date of the person’s registration with their state authority.

Phone number The phone number of the person.

Mobile number The mobile phone number of the person.

emailAddress The email address of the person

Registration

Type Indicates whether the person is registered as an owner or a trainer.

From date The date on which the registration commenced.

Group

Name The name of the group the person belongs to.

From date The date when the person joined the group.

Penalty

Authority The authority which applied the penalty.

Code The code that specifies the penalty.

Commencement date The date the penalty commences.

Expiration date The date the penalty expires.

`



11.5. Attributes of Groups

Entity

Group


Authority The Owning Authority of the group.

State group id The identifier of the group, as assigned by the Owning Authority.

Name The name of the group.

Type The type of group, e.g. partnership or syndicate.

Member

Full name The name of the member.

Is manager Indicates whether the person is the manager of the group.

`



12. Appendix: Description of Types

The Logical Data Model (Section 4.1) specifies a type for each attribute. These types are listed in the tables below.

12.1. Basic Types

The following basic types are considered self-explanatory:

Boolean

Date

Time

String

Integer

Decimal

12.2. Types used across Entities

The following enumerated types are restricted to the Possible Values listed in the table:

Type Possible Values

Authority Type ACT, NSW, NT, NZ, QLD, SA, TAS, VIC, WA, GA

12.3. Types relating to Dogs and Litters



Gender Dog, Bitch, Hermaphrodite, Unknown

The following types are Strings of limited length:

Type Based on Restriction

Earbrand Type String Maximum 250 characters

Dog Name Type String Maximum 250 characters

`



Each of the following tables defines a single enumerated type, and provides a description for each possible value:

Type Possible Values Description

Penalty Code Type F1 Marring (1st Offence)

F2 Marring (2nd Offence)

F3 Marring (3rd Offence)

IL Illness

IN Injury

N1 Non-chasing (1st Offence)

N2 Non-chasing (2nd Offence)

N3 Non-chasing (3rd Offence)

NI Non-chasing - injured

NP Not Presented

SE Seasonal

SI Subject to inquiry

TR Transferred

UP Unsatisfactory Performance

WV Weight Variation

TB Turned in Boxes

WT Whelping Trial

NW Nomination Withdrawal


Service Status Type Active Service has occurred.

Missed Expected whelping data has passed, but no pups have been

born.

No Live Pups Pups were born, but none

survived until notification of Whelping.

Whelped Whelping has occurred, and at least one pup survived until

notification of Whelping.

Invalid The record contains invalid data, and should be ignored.

`




Service Type Natural Natural Service.

FSI Frozen Semen Service.

Unknown Type of Service is unknown.


Dog Grade Type 1 Grade 1

2 Grade 2

3 Grade 3

4 Grade 4

5 Grade 5

6 Grade 6

M Maiden

G Graduation

J Juvenile

Q Qualify

N Novice

Type

Dog Marking Type

Possible Values Description Possible Values Description

U Unknown LTF Light Fawn

BD Brindle LTFW Light Fawn & White

BDW Brindle & White RBD Red Brindle

BDWT Brindle & White Ticked RBDW Red Brindle & White

BE Blue RF Red & Fawn

BEBD Blue Brindle RFW Red Fawn & White

BEBDW Blue Brindle & White W White

BEDUN Blue Dun WBD White & Brindle

BEF Blue Fawn WBDT White with Brindle Ticking

BEFW Blue Fawn & White WBE White & Blue

BEW Blue & White WBEBD White & Blue Brindle

BK Black WBEF White & Blue Fawn

`



Type

Dog Marking Type


BKBD Black Brindle WBET White with Blue Ticking

BKBDW Black Brindle & White WBK White and Black

BKW Black & White WBKBD White & Black Brindle

DKBD Dark Brindle WBKBE White Black & Blue

DKBDW Dark Brindle & White WBKT White with Black Ticking

DKF Dark Fawn WDKBD White and Dark Brindle

DKFW Dark Fawn & White WDKF White and Dark Fawn

DUN Dun WDUN White and Dun

DUNB Dun Brindle WF White and Fawn

DUNF Dun Fawn WFT White with Fawn Ticking

DUNW Dun & White WLTBD White and Light Brindle

F Fawn WLTF White and Light Fawn

FBD Fawn Brindle WRBD White and Red Brindle

FW Fawn & White WRF White and Red Fawn

LTBD Light Brindle WDUNBD White and Dun Brindle

LTBDW Light Brindle & White DUNBDW Dun, Brindle and White

Dog Lifestate is a complex type, consisting of a status, sub status, and further information:

Type Status Sub Status Further

Information

Possible Values

(for Further Information)

Dog

Lifestate

Unnamed (none) (none) (none)

Racing (none) (none) (none)

Retired Pet Keeper owner

trainer

third party

Breeding Keeper owner

leased

`



Type Status Sub Status Further

Information

Possible Values

(for Further Information)

GAP (none) (none)

Surrendered to

another agency

(none) (none)

Exported (none) (none)

Other (none) (none)

Deceased Euthanised Reason injury

unsuitable for rehousing

lack of ability

at track

other

Natural Causes (none) (none)

Accident (none) (none)

Other (none) (none)

The following table defines a single multi-field type:

Type Field Type Description

FSI Details Type Inseminator String The individual (typically a vet) who performed the insemination.

Facility String The name of the facility where the

insemination was performed.

Breeding Unit Service Set

Sequence of Strings

The IDs of the Breeding Units.


Trial Required Info Track Track Code Type The track where the trial is to be performed.

`




Trial Completed Info Track Track Code Type The track where the trial was performed.

Date of Trial Date The date the trial was performed.

Distance Integer The distance of the trial.

Number of Runners Integer The number of runners in the

trial.

Box No Integer The number of the box where the dog started the trial.

Weight Decimal The weight of the dog.

Time Decimal The time achieved by the dog in the trial.

Place Race Result Type The place achieved by the dog in

the trial.

Margin Margin Type The margin of the dog with respect to the winner of the trial.


Penalty Clearance Info Authority Authority Type The authority that cleared the penalty.

Removal date Date The date the penalty was removed.

Cleared date Date The date the dog is cleared to

race.

Trial Completed Trial Completed Info

Provides details of the trial, e.g. track and date of trial.

`



12.4. Types relating to Meetings and Races




PIR String Maximum 5 characters

Comments String Maximum 40 characters


Meeting Type 1 TAB

2 Non-TAB

3 Qualifying


Meeting Slot Type M Morning

D Day

T Twilight

N Night


Rug Type 1 Rug 1

2 Rug 2

3 Rug 3

4 Rug 4

5 Rug 5

6 Rug 6

7 Rug 7

8 Rug 8

9 Rug 9

`




10 Rug 10


Box Type 1 Box 1

2 Box 2

3 Box 3

4 Box 4

5 Box 5

6 Box 6

7 Box 7

8 Box 8


Prize Code Type 1 Owners & Breeders incentive

2 Breeders

3 Trophy

4 (undefined)


Finished Result Type 1 1st Place

2 2nd Place

3 3rd Place

4 4th Place

5 5th Place

6 6th Place

7 7th Place

8 8th Place

1= Equal 1st

2= Equal 2nd

3= Equal 3rd

4= Equal 4th

5= Equal 5th

`




6= Equal 6th

7= Equal 7th


Other Result Type T Tailed Off

P Pulled Up

F Fell

D Disqualified

B Stayed in Box


Non Started Result Type S Scratched

R Reserve

N No Race

A Abandoned

NS Non-Starter

`



Type

Track Code type

Code Track State (info only) Code Track State (info only)

DAR Winnellie Park NT

ALB Albury NSW APP Appin NSW

ARM Armidale NSW BAT Bathurst NSW

BUL Bulli NSW BHL Broken Hill NSW

CAS Casino NSW CES Cessnock NSW

CON Coonabarabran NSW COO Coonamble NSW

COT Cootamundra NSW COW Cowra NSW

DTO Dapto NSW DUB Dubbo NSW

FOR Forbes NSW GBN Goulburn NSW

GOS Gosford NSW GRA Grafton NSW

GRF Griffith NSW GUN Gunnedah NSW

HPK Harold Park NSW KEM Kempsey NSW

LIS Lismore NSW LIT Lithgow NSW

MAT Maitland NSW MOR Moree NSW

MVL Moss Vale NSW MUD Mudgee NSW

MUS Muswellbrook NSW NAR Narrabri NSW

NCL Newcastle NSW NOW Nowra NSW

ORG Orange NSW PEN Penrith NSW

PPK Potts Park NSW QBN Queanbeyan NSW

RIC Richmond NSW SIG Singleton NSW

TAM Tamworth NSW TAR Taree NSW

`



TEM Temora NSW GAR The Gardens NSW

TWH Tweed Heads NSW WAG Wagga Wagga NSW

WAU Wauchope NSW WEN Wentworth NSW

WPK Wentworth Park NSW WOL Wollongong NSW

WYG Wyong NSW YNG Young NSW

ACT Canberra ACT

BAL Ballarat VIC BEN Bendigo VIC

CRN Cranbourne VIC GEL Geelong VIC

HVL Healesville VIC HOR Horsham VIC

SLE Sale VIC SAN Sandown Park VIC

SHP Shepparton VIC MEA The Meadows VIC

TRA Traralgon VIC WTA Wangaratta VIC

WGL Warragul VIC WBL Warrnambool VIC

BGC Albion Park QLD BEE Beenleigh QLD

BUN Bundaberg QLD CAI Cairns QLD

CAP Capalaba QLD GAB Gabba QLD

GCT Gold Coast QLD IPS Ipswich QLD

LAW Lawnton QLD AYR Ayr QLD

MCK Mackay QLD MTI Mt Isa QLD

ROC Rockhampton QLD TOW Townsville QLD

TWB Toowoomba QLD

APK Angle Park SA BAR Barmera SA

`



GAW Gawler SA KUL Kulpara SA

MTG Mount Gambier SA PTA Port Augusta SA

PTL Port Lincoln SA PTP Port Pirie SA

STR Strathalbyn SA WHY Whyalla SA

CAN Cannington WA MAN Mandurah WA

NOR Northam WA

DEV Devonport TAS HOB Hobart TAS

LCN Launceston TAS

ASH Ashburton NZ AUK Auckland NZ

CCH Christchurch NZ MAW Manawatu NZ

OTG Otago NZ PNN Palmerston North

NZ

SOU Southland NZ TAK Taranaki NZ

TOK Tokoroa NZ WAN Wanganui NZ

WAK Waikato NZ WAI Wairarapa NZ

WEL Wellington NZ ADD Addington NZ

INT International Other

Type

Race Grade Type


`



Type

Race Grade Type


1 Grade 1 X12 Mixed 1/2




5 Grade 5 X45H Mixed 4/5 Heat

5Q Grade 5 Quali X45F Mixed 4/5 Final

5QF Grade 5 Quali Final X123 Mixed 1/2/3

FFA Free for All X12NP Mixed 1/2 Non Penalty

FFANP Free for All Non Penalty X23NP Mixed 2/3 Non Penalty

I Invitation X34NP Mixed 3/4 Non Penalty

J Juvenile X45NP Mixed 4/5 Non Penalty

X345 Mixed 3/4/5 X234 Mixed 2/3/4

M Maiden 5NP Grade 5 Non Penalty

MSF Maiden Semi Final 5NPH Grade 5 Heat Non Penalty

MHH Maiden Heat (Half Stakes) 4NP Grade 4 Non Penalty

MF Maiden Final 3NP Grade 3 Non Penalty

MH Maiden Heat 2NP Grade 2 Non Penalty

MQH Maiden Quali Heat 1NP Grade 1 Non Penalty

MQF Maiden Quali Final NNP Novice Non Penalty

5N Novice Grade 5 5F Grade 5 Final

NNP Novice Non Penalty MH Maiden Heat

NNPH Novice Non Penalty Heats 5H Grade 5 Heat

NH Novice Heat 5QH Grade 5 Quali Heat

HCP Handicap SH Special Event Heat

S Special Event SSF Special Event Semi Final

SH Special Event Heat AAX All Age Mixed

SF S/E Final HDL Hurdle

GRP1 S/E Group 1 B8 Best Eight

GRP2 S/E Group 2 GRAD Graduation

GRP3 S/E Group 3 N Novice

GL S/E Group Listed ST Stewards Trial

SNP S/E No Penalty RWNP Restricted Win Non Penalty

`



Type

Race Grade Type


X Mixed RWH Restricted Win Heat

XM5 Mixed M/5 O Open

SHNP Special Event Heat Non Penalty T3-M Tier 3 Maiden

NF Novice Final XM6 Mixed Maiden Grade 6

6Q Grade 6 Quali MJ5 Maiden Juvenile Grade 5

X45M Mixed Grade 5 Grade 5 Maiden 2Q Grade 2 Quali

C Consolation T3-5H Tier 3 Grade 5 Heat

VET Special Event Veteran 3Q Grade 3 Quali

JM Juvenile Maiden 4Q Grade 4 Quali

AMM Maiden QF Qualifying Final

GQ Graduation Quali T3-5 Tier 3 Grade 5

6 Grade 6 RWF Restricted Win Final

RW Restricted Win XMG Mixed Maiden Graduation

XP Mixed Non Penalty VETH Veteran Heat

VETF Veteran Final 2F Grade 2 Final

3F Grade 3 Final 4F Grade 4 Final

XRA Mixed Restricted Age XRAF Mixed Restricted Age Final

XRAQ Mixed Restricted Age Quali

Each of the following tables defines a single multi-field type:


Race Results Info Type Win Time Decimal Winning time.

Split1 Decimal Time recorded for 1st split.

Split1RugNo Integer Rug number of the dog that set the 1st split time

Split2 Decimal Time recorded for 2nd split.

Split2RugNo Integer Rug number of the dog that set the 2nd split time

Split3 Decimal Time recorded for 3rd split.

Split3RugNo Integer Rug number of the dog that set

the 3rd split time

`



`



12.5. Types relating to Persons and Groups



Title Type Mr, Mrs, Miss, Ms, Dr, Prof

State Type ACT, NSW, NT, NZ, QLD, SA, TAS, VIC, WA, INTL



Party Name Type String Maximum 250 characters

Phone Type String A 10 digit number commencing

with a “0” (domestic)

Or

A “+” followed by an arbitrary

number of digits (international)

Each of the following tables defines a single multi-field type:

Type Field Type

Person Name Type Title Title Type

First Name String

Middle Init String

Surname String

Type Field Type

Address Type Street String

Suburb String

State String

Postcode String

Country String

`





Person Registration Type 0 Unregistered

1 Trainer

2 Owner


Person Penalty Code Type 1 Defaulter

2 Suspended

3 Disqualified

4 Subject to Enquiry


Group Type S Syndicate

P Partnership

`



12.6. Types relating to Events

The following tables defines a single multi-field type:


Event Details Type Owning Authority Authority Type The Owning Authority of the

Entity, after the Event.

Transaction Authority

Authority Type The authority which initiated the Event (e.g. by updating the

Entity.)

Previous Authority Authority Type The Owning Authority of the

Entity, prior to the Event.

Event Type Event Type The type of Event.

Name String The name of the Entity.

Old Name String The previous name of the Entity

(populated in case the Event related to the renaming of the

Entity).

Etag String The etag corresponding to the updated Entity.

Description String A free text description of the event.

The following table defines a single enumerated type, and provides a description for each possible value:

Type Possible Values Entity Business Operation

(per Section 5.1 )

Event Type

DogNew Dog Create

DogUpdate Dog Update

DogUpdateEarbrand Dog Update (earbrand)

DogName Dog Update (name)

DogDna Dog Update (dna)

DogUpdateStudsire Dog Update (studsire)

DogUpdateLifestate Dog Update (lifestate)

DogUpdateMicrochip Dog Update (microchip)

DogUpdateCertificate Dog Update (certificate)

DogUpdateOwner Dog Update (owner)

DogUpdateTrainer Dog Update (trainer)

`



Type Possible Values Entity Business Operation

(per Section 5.1 )

DogUpdatePenalty Dog Update (penalty) – create a new penalty

DogUpdatePenaltyModify Dog Update (penalty) – modify an existing penalty

LitterNew Litter Create

LitterUpdate Litter Update

LitterUpdateWhelping Litter Update (whelping)

MeetingNew Meeting Create

MeetingUpdate Meeting Update

PersonNew Person Create

PersonUpdate Person Update

PersonMove Person Update (authority)

PersonUpdatePenalty Person Update (penalty) – create a new penalty

PersonUpdatePenaltyModify Person Update (penalty) – modify an existing penalty

PersonUpdateGroupMembership Person Update

GroupNew Group Create

GroupUpdate Group Update