1.7.1 <Contacts>

The <Contact>s element is specifically for parties that are expecting to be contacted in connection with the element that they are contained within. The choice of which element the <Contacts> is contained within should imply the role of the <Contact> elements that it contains.

The primary reason for having a <Contacts> element rather than just placing the <Contact> elements inside the parent is that it provides a place to define a <Description> that may be used as a non-structured alternative to the <Contact> elements if the structured data is not available.

Attributes

May Contain

Choice

 

Structured

 

<Contact(Reference)>

(), compulsory and repeatable

<Description(Reference)>

(), optional and repeatable. If you are going to provide a <Description> as well as one or more <Contact> elements then the <Description> should describe the Contacts as a whole. If the Description actually describes a single <Contact> then it should be included as a child of the <Contact> in question ()

Descriptive

 

<Description(Reference)>

(), compulsory and repeatable. If you are not going to provide any structure <Contact> elements then you have to provide at least one descriptive element to provide a human readable alternative.

<Link(Reference)>

(), optional and repeatable

<Property>

, optional and repeatable

Contained Within

<Event>

, optional. The <Contacts> element inside the <Event> itself should contain any parties that should be contacted about the event for reasons other than ticketing and venue purposes.

<Tickets>

, optional. A <Contacts> element inside a <Tickets> element should list bodies that should be contacted in connection with the purchasing of tickets.

<Venue>

, optional. A <Contacts> element inside a <Venue> element should list bodies that should be contacted in connection with the containing venue, eg opening times, parking, disabled access etc etc.

<VenueDefinition>

, optional. Same role as within <Venue>.