University of California, Berkeley e-Berkeley Program Office UC Berkeley Calendar Network Allison Bloodworth This document incorporates UC Berkeley Calendar Event modeling work done by Allison Bloodworth, Sara Leavitt, Lawrence Hall of Science, Kathleen Connors, Lawrence Hall of Science, Jeff McCullough, CalAgenda, Sarah Jones, CalAgenda and Mimi Mugler, Cal Agenda during 2003-2004. This file contains a W3C XML schema definition for a group of public calendar Events. The model was created based on a study of events in web-based university event calendars. Last updated: 8/25/05 This is a "Garden of Eden" style schema where all the elements and types are global to allow for redefines and substitution groups. Redefines are useful for creating enumerated types for elements, and substitution groups are useful for creating an element that can substitute for another one. For instance, a "Performance Event" might have different elements and constraints, but using a substitution group it can be substituted for a generic Event. Container elements are used whenever an element is unbounded. Almost all top-level elements directly under Event are optional and unbounded (inside a container element) to allow for maximum reusability of the schema. Exceptions to this rule include EventTitle and DateTime, as we consider these to be the "Core" of an Event, which all events should contain. Most other elements are also optional, and many are unbounded (inside a container element). However, at least one element is required if a container for it exists, although the container itself is optional (e.g. a Sponsor within the Sponsors elements) and all boolean elements can occur between 0-1 times (meaning they can't be unbounded). Additionally, elements that describe their parent element for which there should clearly only be one are not unbounded. The DateTime section of the schema is based on the IETF iCalendar Specification, RFC 2445, available at http://www.ietf.org/rfc/rfc2445.txt. We recommend that all users of this schema follow the guidelines set forth in RFC 2445. We suggest that users of this schema either use redefines, substitution groups, or restrictions to represent any additional business rules required in their particular situation. Additionally, this schema uses xs:anyType, the universal type which accepts any content model, to allow users to define any additional elements of an Event which may be required. Something that takes place; an occurrence. The unique identifier of an event. The EventID itself should be a globally unique identifier. From iCalendar (RFC-2445) specification: "The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [RFC 822] addr-spec. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of the "@", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number)." Adapted from RFC 2445: "The full range of calendar Events specified by a recurrence set (a set of recurring events which are grouped together, most likely because they were initially entered into the system together, and which are united by a series of RecurrenceDates or RecurrenceRules) is referenced by referring to just the EventID property value corresponding to the calendar component. The RecurrenceID property allows the reference to an individual instance within the recurrence set. This property is an important method for group scheduling applications to match requests with later replies, modifications or deletion requests." "The "RecurrenceID" property is used in conjunction with the "EventID" and "Sequence" property to identify a particular instance of a recurring event." The primary title of an Event. Any additional or secondary information that is part of the title of an Event. The day and time an Event occurs. Includes information on repetition. The place or places the event occurs. A categorization or categorizations of the event (e.g. Lecture, Seminar, Performance, etc.). This type allows for a hierarchy of Event types if necessary. Languages spoken at the Event An indicator that an Event is transparent and doesn't take up time on an event calendar, or show up on free/busy time searches of a personal calendar. By default, Events are "Opaque". Events such as anniversaries and holidays may be "Transparent". Another special type for Event calendars is "TransparentToChild". This type is useful in situations where there is a parent event, such as a conference, which should take up an entire block of time but should also display their child events, such as certain presentations, inside of it. An overall description of the Event. A shortened description of the Event which may be used when a shortened description of an event may be needed, such as highlighting an event on a home page. A webpage or webpages dedicated to the Event. A webcast or webcasts of the Event. An image or images associated with the Event. An document or documents associated with the Event. People or organizations who are participating in the event; attendees. This type allows for a hierarchy, or group, of Participants if necessary. Featured participants at the event who are speaking or performing in some way (e.g. Speaker, Lecturer, Discussant, Performer, Dancer, etc.). This type allows for a hierarchy, or group, of Performers if necessary. Entities who are putting on the event, sponsoring the event financially, or are otherwise known as an organizer or supporter of the Event. This type allows for a hierarchy, or group, of Sponsors if necessary Information on tickets, registration, enrollment, reservations, RSVP, etc., target audiences, open to audiences, attendance restrictions, and accessibility info for people with disabilities. Entities who are responsible for maintaining the Event in the Calendar network. This type allows for a hierarchy, or group, of Event Owners if necessary. A person or list of persons for the public to contact with questions about the Event. This type allows for a hierarchy, or group, of Public Event Contacts if necessary. A person or list of persons for calendar administrators to contact with questions about an Event. This type allows for a hierarchy, or group, of Event Listing Contacts if necessary. Indicates whether or not the Event is definitely scheduled to take place. This is a term used by iCalendar (RFC 2445) and could include statuses such as tentative, confirmed, and canceled. Indicates how and whether the Event with be shared with other calendars or users. This is a term used by iCalendar (RFC 2445) and could include classifications such as public, private, and confidential. Indicates when and by whom the Event was entered, and when and by whom the Event was modified. Other events which bear some relation to the Event. This could be a parent, child, or sibling relationship, or an indicator re: another event that may also be of interest to people attending the Event. If an event is special and should be featured in some way, the way or place the event should be featured can be described here. It is often used as a marketing tool. If there is additional promotional material available re: the event, such as a poster or third party review, it may be documented here. An open-ended comments field that is not displayed on any public website, but may be seen by calendar administrators or people who can edit the event. This may be used along with FeaturedEventTypes or when events are recommended to explain to calendar administrators why they should publish or feature the event on their website. Specialized terms describing an Event that may be used to help users searching for events find events of interest to them. Information on refreshments, food, or meals that will be served at the Event. This element is used so that elements may be added via in the same namespace via xs:any while retaining the extensibility point and without violating the unique particle attribution rule. This element may be used to add an element not otherwise covered in this schema which is in a different namespace to an Event. This element may be used to add an attribute not otherwise covered in this schema to an Event. It may be in the target or other namespace because the problems with xs:any elements in the same namespace don't occur with xs:anyAttribute. This element allows for the creation of a hierarchy, or group, of Event Types. This property defines the number number of a clip in a series of clips that comprise the webcast. Potential phone number types may include home, cell, office, fax, and other. May be used to indicate characteristics of a particular group of participants (e.g. participant's role at the event, invited participants, participants who have RSVP'd, etc.). An image associated with the participant. A description of the participant. This may be a biography. This element allows for the creation of a hierarchy, or group, of Participants. Indicates what type of performance or performances the performer will be putting on at the Event (e.g. Speaker, Dancer, etc.). An image associated with the performer. A description of the performer. This may be a biography. This element allows for the creation of a hierarchy, or group, of Performers. If a system requires that Sponsors be distinguished from each other, it may be done with this element. This element allows for the creation of a hierarchy, or group, of Sponsors. Groups for whom the Event is intended. Groups to whom the Event is open, but not necessarily targeted. Enumerates any restrictions on entry (e.g. No children under 18, ID required, etc.). Groups of information related to different types of admission requirements (e.g. tickets, registration, enrollment, reservations, RSVP, etc.). Information on access to the event for people with disabilities (e.g. sign language presentation availability, wheelchair access, etc.). Type of admission information provided by this group (e.g. tickets, registration, enrollment, reservations, RSVP, etc.). Is it required, recommended, or in some other way advised that the type of this AdmissionInfoGroup (tickets, registration, enrollment, reservations, RSVP, etc.) be purchased or completed in some way? The date the tickets go on sale, or the registration, RSVP, enrollment, etc. begins. The deadline by which registration, enrollment, RSVP, etc. must be completed. Indicates the current status of the Admission Info Group. For instance, it could be used to indicate whether registration, enrollment, etc. is open or closed, or whether tickets are sold out. May be used to indicate any additional info about the Admission Info Group. For instance, if there are restrictions on the methods of payment such as the use of only a major credit card. Indication of what level of tickets (e.g. Orchestra, Balcony), audience, or other parameter (such as what audience) to which the associated Admission Price applies. If a system requires that Event Contacts be distinguished from each other, it may be done with this element. This element allows for the creation of a hierarchy, or group, of Event Contacts. If a system requires that Event Owners be distinguished from each other, it may be done with this element. This element allows for the creation of a hierarchy, or group, of Event Owners. Adapted from RFC 2445: This property defines the revision sequence number of the Event within a sequence of revisions. A webpage or webpages for the location of the Event. A link or links to a map of the location of the Event. Any additional information for the public about the location (e.g. handicapped access, directions, etc.). StartDate and EndDate describe the start and end of a single Event instance. In the case of a recurring Event (a series of event instances that repeat in a manner defined by RecurrenceRule(s) and/or RecurrenceDate(s)), they describe the start and end of only the first instance of an Event, not the start and end of the entire recurrence set. Date the Event (for non-recurring events) or first instance of the Event (for recurring events) begins. Events can have a StartDate but no EndDate. In that case, the event does not take up any time (which is useful for Events such as holidays and deadlines). If an Event that takes up no time spans more than one day and thus has an EndDate, there must not be an EndTime. Another way of handling this type of event, however, is to set the EventTransparency to "Transparent." The use of the xs:date datatype allows for the inclusion of a timezone offset in the StartDate if desired. Time the Event (for non-recurring events) or first instance of the Event (for recurring events) begins. Events which take up time must have a StartTime. The use of the xs:time datatype allows for the inclusion of a timezone offset in the StartTime if desired. The date and time an Event (for non-recurring events) or first instance of the Event (for recurring events) ends. Events which take up no time (e.g. holidays) may have no EndDateTime. EndDate and EndTime are grouped together only because either EndDate or both EndDate and EndTime is an alternative to Duration. Primitive type which allows durations to be represented. It is recommended that the ISO-8601 basic format PnYnMnDTnHnMnS where nY = number of years, nM = number of months, nD = number of days, nH = number of hours, nM = number of minutes and nS = number of seconds is used. It is calculated inclusive of the StartDate. Adapted from RFC 2445: "This property is used in conjunction with the EventID and SequenceNumber property to identify a specific instance of a recurring Event. The full range of Events specified by a recurrence set is referenced by referring to just the EventID corresponding to the Event. The RecurrenceID, which consists of the date of the Event instance in question, allows the reference to an individual instance within the recurrence set." "The "RecurrenceID" property is used in conjunction with the "EventID" and "Sequence" property to identify a particular instance of a recurring event, to-do or journal. For a given pair of "EventID" and "Sequence" property values, the "RecurrenceID" value for a recurrence instance is fixed. When the definition of the recurrence set for a calendar component changes, and hence the "Sequence" property value changes, the "RecurrenceID" for a given recurrence instance might also change." Specific dates on which an event repeats. Often used instead of a Recurrence Rule when the repetition doesn't not follow a pattern, and may also be used in conjunction with a Recurrence Rule. In certain implementations it may also include Recurrence Dates calculated based on a Repetition Rule. Adapted rom RFC 2445: "The recurrence set is the complete set of recurrence instances for a calendar component. The recurrence set is generated by considering the initial "StartDate" property along with the "RecurrenceRule", "RecurrenceDate", "ExceptionDate" and "ExceptionRule" properties contained within the iCalendar object. The "StartDate" property defines the first instance in the recurrence set. Multiple instances of the "RecurrenceRule" and "ExceptionRule" properties can also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the start date-times generated by any of the specified "RecurrenceRule" and "RecurrenceDate" properties, and then excluding any start date and times which fall within the union of start date and times generated by any specified "ExceptionRule" and "ExceptionDate" properties." Rules defining when and how often an Event recurs or repeats (e.g. every Tuesday and Thursday). Adapted from RFC 2445: "This property defines the list of date/time exceptions for a recurring Event." (E.g. a conference spanning two weeks may not occur over a weekend, or a recurring event may not occur during winter break.) In certain implementations it may also include exception dates calculated based on an Exception Rule. From RFC 2445: "This property defines a rule or repeating pattern for an exception to a recurrence set." Often used to define exception dates with a period (e.g. the event occurs every Monday for the next 6 months, except the 1st Monday of the month.) Date the Event (for non-recurring events) or first instance of the Event (for recurring events) ends. The use of the xs:date datatype allows for the inclusion of a timezone offset in the EndDate if desired. Time the Event (for non-recurring events) or first instance of the Event (for recurring events) ends. The use of the xs:time datatype allows for the inclusion of a timezone offset in the EndTime if desired. Adapted from RFC 2445: "The value is the effective value of the StartDate of the Event instance within the recurrence set." "The RecurrenceID is used in conjunction with the EventID and Sequence to identify a particular instance of a recurring event. For a given pair of EventID and SequenceNumber values, the RecurrenceID value for a recurrence instance is fixed. When the definition of the recurrence set for a calendar component changes, and hence the Sequence value changes, the RecurrenceID for a given recurrence instance might also change." "The value is set to the time when the original recurrence instance would occur; meaning that if the intent is to change a Friday meeting to Thursday, the date/time is still set to the original Friday meeting." Adapted from RFC 2445: The element specifies the effective range of recurrence instances that is specified by the property. The effective range is from the recurrence identified specified by the RecurrenceIDDate. If Range is not specified on a RecurrenceID, then the default range is the single instance specified by the RecurrenceIDDate. Values may include "ThisAndPrior" to indicate a range defined by the RecurrenceIDDate and all prior instances. The parameter value can also be "ThisAndFuture" to indicate a range defined by the recurrence identifier and all subsequent instances. Date the recurrence or exclusion instance begins. The use of the xs:date datatype allows for the inclusion of a timezone offset in the StartDate if desired. Time the recurrence or exclusion instance begins begins. The use of the xs:time datatype allows for the inclusion of a timezone offset in the StartTime if desired. Date and time the recurrence or exclusion instance ends. EndDate and EndTime are grouped together only because either one or both is an alternative to Duration. Primitive type which allows durations to be represented. It is recommended that the ISO-8601 basic format PnYnMnDTnHnMnS where nY = number of years, nM = number of months, nD = number of days, nH = number of hours, nM = number of minutes and nS = number of seconds is used. It is calculated inclusive of the StartDate. Date the recurrence or exclusion instance ends. The use of the xs:date datatype allows for the inclusion of a timezone offset in the EndDate if desired. Time the recurrence or exclusion instance ends. The use of the xs:time datatype allows for the inclusion of a timezone offset in the EndTime if desired. The date a recurrence or exclusion instance occurs. When indicating the type of a RecurrenceIDDate, it is the date of the recurrence instance. The use of the xs:date datatype allows for the inclusion of a timezone offset in the Date if desired. The time a recurrence or exclusion instance occurs. When indicating the type of a RecurrenceIDDate, it is the time of the recurrence instance. The use of the xs:time datatype allows for the inclusion of a timezone offset in the Time if desired. Per RFC 2445, ExceptionDates may not be periods. Periods are allowed for RecurrenceDates, however. Indicates how frequently an event repeats (e.g. hourly, daily, weekly, monthly, yearly). Indicates the number of units of frequency on which event repeats (e.g. every 2 hours, every 5 days, etc. Indicates the number of times an event repeats (e.g. daily for 10 days). This element or Until is usually required for a recurring event. If neither Count nor Until is present, the event is considered to repeat forever. From RFC 2445: "The UNTIL rule part defines a date-time value which bounds the recurrence rule in an inclusive manner." The recurrence repeats "until" (inclusively) the date-time specified. Indicates the minute of the hour on which an event repeats (e.g. to repeat every 20 minutes for an hour, ByMinute would have values of 0, 20, and 40. ByHour would also need to be used to indicate which hour.) This element should be limited to values 0 through 59. Indicates the hour of the day, using a 24-hour clock, on which an event repeats (e.g. to repeat at 10am, 2pm, and 4pm, ByHour would equal 10, 14, and 16). This element should be limited to values 0 through 23. Indicates the days of the week on which an event repeats. It can also include a positive or negative number to indicate, for example, "the third Monday of the month" or "the last Friday of the year" if the Frequency is set to something other than weekly (e.g. to repeat every third Monday of the month, DayInterval would be "3," and DayOfWeek would be "Monday"). Indicates the week of the year on which an event repeats (e.g. the 5th week of the year). Negative values may also be used to indicate how close the week is to the end of the year (e.g. "-1" means the last week of the year), and thus this element should be limited to values -53 through 53, not including 0. Indicates the month of the year on which an event repeats (e.g. the 7th month of the year, July.). This should be limited to values 1-12. Indicates the day of the month on which an event repeats (e.g. the 31st day of the month.). Negative values may also be used to indicate how close the week is to the end of the month (e.g. "-1" means the last day of the specified month), and thus this element should be limited to values -31 through 31, not including 0. Indicates the day of the year on which an event repeats (e.g. the 1st and 200th days of the year. Negative values may also be used to indicate how close the day is to the end of the year (e.g. "-1" means the last day of the year), and thus this element should be limited to values -366 through 366, not including 0. Indicates the instance of the set of days on which the event will repeat. (E.g. if ByDayOfWeek is set to "Mon, Tues, Wed, Thurs, Fri", and you'd like the event to repeat for the next month every 2nd weekday, "BySetPosition" would be 2). Negative values may also be used to indicate how close the day is to the end of the set (e.g. "-1" means the last day of the set), and thus this element should be limited to values -366 through 366, not including 0. Allows users to define any set of seasons that is useful in their domain. Defines which day of the week (e.g. Mon) on which a workweek starts. The default should be Monday. This is significant when a WEEKLY repetition rule has an interval greater than 1, and a BYDAYOFWEEK rule part is specified. This is also significant when in a YEARLY repetition rule when a BYWEEKNO rule part is specified. In this situation, WeekStart determines which week of the year is considered week 1, as week number one of the calendar year is the first week which contains at least four (4) days in that calendar year (from the iCalendar Specification, RFC 2445). The date until which (inclusive of this date) an Event occurs. The use of the xs:date datatype allows for the inclusion of a timezone offset in the Date if desired. The time until which (inclusive of this time) an Event occurs. Indicates that it is the nth day of the interval. For example, 1 and Monday indicates that it is the first Monday of the specified interval. Negative numbers can also be used to indicate that it is the last (-1), second to the last (-2), etc. weekday of the specified interval.