University of California, Berkeley e-Berkeley Program Office UC Berkeley Calendar Network Allison Bloodworth This schema redefines simple and complex types to add codelists and place additional restrictions on the Events_1.9.xsd schema to create a modified schema that matches the business requirements of the University of California, Berkeley. This file uses derivations by restriction only, and is an intermediary transform that supports the final schema, UCBEvents.xsd. An instance document that conforms to this schema and UCBEvents.xsd will also conform to Events_1.9.xsd. Business Rules defined in this and the UCBEvents.xsd schema: 1) Events currently may not specify an EventID, Languages, EventTransparency, Participants, Event Owners, ChangeManagement, RelatedEvents or EventPromotions. 2) Any elements added via Extension or xs:any will be ignored. 3) Events may not specify an EventOwner. 4) An Event must have at one and only one Location. Only one LocationType must be specified. We would like to require LocationID for “On Campus” LocationType; anything without a LocationID should be “Off Campus”, but we need Schematron to do this. We would also like to allow WebPages and MapLinks for "On Campus" locations only, but again need Schematron. We would also like to remove all Address elements except Room for "On Campus" locations, but need Schematron. 5) An Event must have at least one EventType and no more than two EventTypes. A schematron rule must be created to specify that the first EventType should be of EventTypeType="Primary" and if a second EventType exists, it must be of EventTypeType="Secondary". We would like to require an EventTypeID not allow Name for “Primary” Event Types, and allow an Event Type of anything other than “Primary” to have a Name or an ID, but not both, but we need Schematron to do this. 6) An Event must have at least one EventListingContact. A ContactName or ID must be specified for the EventListingContact, but specifying this requires Schematron. It may not have ProfessionalAffiliations, Phones, EmailAddresses, Addresses, WebPages, or a PreferredContactMethod. 7) An Event must have a Status. 8) An Event must have a Classification. 9) An Event may have only one Webcast. 10) An Event may only have one Image. A Title and URL only may be specified for the Image. 11) A ShortDescription must not contain any element content (e.g. HTML tags). 12) A PersonalName must have only one FullName and nothing else. 13) When an element has Phones, only one Phone is allowed. 14) When an element has EmailAddresses, only one EmailAddress is allowed. 15) An Event may have only one PrivateComment. 16) When an element has WebPages or OrganizationWebPages, only one WebPage URL may be specified. A Title is not allowed. 17) When an element has ProfessionalAffiliations, only one ProfessionalAffiliation is allowed. 18) When ane element has JobTitles, only one JobTitle is allowed. 19) When an element has MapLinks, only one MapLink is allowed. 20) When an element has Addresses, only one Address is allowed. The Address may not have an ID, Floor, Additional Street Name, Building Name, Building Number, InhouseMail, Department, CountrySubentityCode, Region, District, TimeZoneOffset, AddressLine, Country or LocationCoordinate. 21) The contents of ContactInfo vary by element. It does not include a PreferredContactMethod. 22) A Phone may not include a PhoneNumberExtension or PhoneNumberType. 23) A Performer may not have a PerformerID, ContactInfo, Images, or a Description, and may have only one PerformerType. No Performer Groups are allowed, so PerformerParentID may not be used. 24) A Sponsor may not have ProfessionalAffiliations, ContactInfo, Images, Description, or a SponsorParentID. Only one SponsorType may be specified for each Sponsor. A Schematron rule must be created to say that there must be one and only one Sponsor of SponsorType="Primary" who has editing privileges on the Event. Any other Sponsors must be marked as SponsorType="Secondary" or higher. We would like to require a SponsorID not allow Name for “Primary” Sponsors only, and require that a Sponsor of any SponsorType other than “Primary” have a Name or an ID, but not both, but we need Schematron to do this. 25) A PublicEventContact does not have a PublicEventContactID, PublicEventContactTypes, a PublicEventContactParentID, WebPages, or OrganizationWebPages. One PublicEventContact PhoneNumber is required. 26) EntryConditions may not have AccessibilityInfo. 27) There may be only one AttendanceRestriction field per Event. All AttendanceRestrictions should be listed in this element. 28) An AdmissionInfoGroupCharge does not have a Currency. 29) Only one AdmissionInfoGroupType and AdmissionInfoGroupContact is allowed per AdmissionInfoGroup. An AdmissionInfoGroupContact may not have an AdmissionInfoGroupContactID, ProfessionalAffiliations, Addresses, or a PreferredContactMethod. A set of Schematron rules is needed to specify that certain other AdmissionInfoGroup elements are not allowed for specific AdmissionInfoGroupTypes. These include 1) If AdmissionInfoGroupType = "Tickets", a Deadline is not allowed, 2) If AdmissionInfoGroupType = "Reservations", AdmissionInfoGroupCharges and DateAvailable are not allowed, and 3) If AdmissionInfoGroupType = "RSVP", AdmissionInfoGroupStatus, AdmissionInfoGroupCharges and DateAvailable are not allowed. 30) DateTime may not include Duration, EndDate, RecurrenceDates, RecurrenceID, ExceptionDates, or ExceptionRules. 31) Only one RecurrenceRule may be specified. It must contain Until, but cannot contain Count. Until cannot contain a Time. 32) For elements with enumerated lists specified below, values submitted must match one of the choices listed. FeaturedEventType and (Webcast) PlayerType include suggestions for values, but will allow others as well. The only business rules which it was not possible to specify in this schema (see PreUCBEvents.xsd and UCBEvents.xsd for schemas validating this rule) include: 1) An PublicEventContact must have a PhoneNumber. Last updated: 10/23/06 This element was minOccurs="0" in Events_1.9.xsd. This element was minOccurs="0" in Events_1.9.xsd. A schematron rule must be created to say that there must be one EventType of EventTypeType="Primary" and, if a second EventType exists, it must be of EventTypeType="Secondary" This element was minOccurs="0" in Events_1.9.xsd. A schematron rule must be created to say that there must be one Sponsor of SponsorType="Primary". This element was minOccurs="0" in Events_1.9.xsd. This element was minOccurs="0" in Events_1.9.xsd. This element was minOccurs="0" in Events_1.9.xsd. This element was minOccurs="0" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. A schematron rule must be created to say that there must be one EventType of EventTypeType="Primary" and, if a second EventType exists, it must be of EventTypeType="Secondary". We would like to require an EventTypeID not allow Name for “Primary” Event Types, and allow an Event Type of anything other than “Primary” to have a Name or an ID, but not both, but we need Schematron to do this. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. Indicates what type of performance or performances the performer will be putting on at the Event (e.g. Speaker, Dancer, etc.). This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. We would like to require a SponsorID not allow Name for “Primary” Sponsors only, and require that a Sponsor of any SponsorType other than “Primary” have a Name or an ID, but not both, but we need Schematron to do this. We also wanted to specify that either a SponsorID, a Name or both must be submitted, but that violated the Unique Particle Attribution rule, so we were unable to do so. This choice also contained the ev:personalName group in Events_1.9.xsd. This element was minOccurs="0" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This choice also contained the ev:OrganizationName element in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was minOccurs="0" in Events_1.9.xsd. This choice also contained the ev:OrganizationName element in Events_1.9.xsd. 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.). This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. 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. This element was maxOccurs="unbounded" in Events_1.9.xsd. This choice also contained the ev:OrganizationName element in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. We would like to require LocationID for “On Campus” LocationType; anything without a LocationID should be “Off Campus”, but we need Schematron to do this. This element was minOccurs="0" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. 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. 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. 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. 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. This element was minOccurs="0" in Events_1.9.xsd. 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 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"). 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. This element was maxOccurs="unbounded" in Events_1.9.xsd. This element was maxOccurs="unbounded" in Events_1.9.xsd. ABIE Address. Details the particulars that identify and locate the place where someone lives or is situated, or where an organisation is situated. Address BBIE Address. Postbox. Text a post office box number or a numbered post box in a post office assigned to a person or organization where letters for them are kept until called for, used as part of an address. 0..1 Address Postbox Text Text. Type PostBox, PO Box "123" BBIE Address. Room. Text identifies the room, suite or apartment as part of an address. 0..1 Address Room Text Text. Type SubPremiseNumber "Reception" BBIE Address. Street Name. Name the name of the street, as part of an address. 0..1 Address Street Name Name Name_Text. Type Thoroughfare "Kwun Tong Road" BBIE Address. City Name. Name the name of the city, town, village, or a built up area and used as part of an address. 0..1 Address City Name Name Name_Text. Type LocalityName "Hong Kong" BBIE Address. Postal_ Zone. Text the identifier for one or more properties according to the postal service of that country; a group of letters and/or numbers added to the postal address to assist in the sorting of mail. 0..1 Address Postal Zone Text Text. Type PostalCodeNumber "SW11 4EW" "2500 GG" BBIE Address. Country Subentity. Code the code that identifies the territorial division (a chief unit of local administration) of a country, as part of an address. 0..1 Address Country Subentity Code Code. Type AdministrativeAreaCode, State Code We are not using this element but the suggested choices are listed here for reference. We are not using this element but the suggested choices are listed here for reference. We are not using this element but the suggested choices are listed here for reference. We are not using this element but the suggested choices are listed here for reference. We are not using this element but the suggested choices are listed here for reference.