On 3/22/15 10:48 AM, Considine, Toby wrote: OK, So an Availability has * more stuff * than a recurrence. Are there any elements of a recurrence that an Availability should * not * have? < xs:element ref = mpsm:dtStart minOccurs = 1 maxOccurs = 1 /> < xs:element ref = mpsm:rDate minOccurs = 0 maxOccurs = unbounded /> < xs:element ref = mpsm:recurrenceRule minOccurs = 1 maxOccurs = unbounded /> < xs:element ref = mpsm:exDate minOccurs = 0 maxOccurs = unbounded /> < xs:element ref = mpsm:dtEnd minOccurs = 0 maxOccurs = 1 /> A dtStart A possible list of one or more explicit recurrence dates One or more recurrence rules A possible list if dates to be excluded A possible end date No - needs them all Also, on a related issue, may a recurrence object have zero recurrenceRules (RRules)? I am working on the model that a recurrence is a means to get a set of start DateTimes. The first element of the set is the dtStart. The RRules are used to compute additional start Dates in using dtStart as an starting point The rDates explicitly add additional members to the set. The exDates explicitly remove members from the set already computed If this is correct, then zero rRules sh ould be legitimate. If not in RFC5545, it could be in the PIM. Zero rrules is legal - a recurring entity has rrrules and/or rdates. But a recurrence is NOT just a means of creating start dates - it's a means of replicating an entity according to rules or by explicitly statibg the recurrence date. The instance of the entity has all (almost) the properties of the master entity. I'm not seeing why you want to ignore that factor when that's what makes recurrences useful. A set of start dates by themselves aren't that useful. It's having the associated information. And finally, to clear up fog in my mind Can a single recurrence have more than one rRule based on the [single] initial dtStart? “Starting January 1, we will meet each Tuesday as well as the 3 rd Thursday of each month” This used to be legal. On the grounds that nobody implemented it they (editors of 5545) decided that only a single rrule should be allowed. I found that a weak argument. They also banned exrules for the same reason. Tc “It is the theory that decides what can be observed. —Albert Einstein Toby Considine Phone: (919)962-9073 Information Technology Services University of North Carolina Chapel Hill, NC Email:
Toby.Considine@unc.edu Chair, OASIS OBIX Technical Committee Chair, OASIS WS-Calendar Technical Committee Editor, OASIS EMIX, Energy Interoperation TC From:
ws-calendar@lists.oasis-open.org [ mailto:
ws-calendar@lists.oasis-open.org ] On Behalf Of Mike Douglass Sent: Saturday, March 21, 2015 10:25 PM To:
ws-calendar@lists.oasis-open.org Subject: Re: [ws-calendar] Schema for Recurrence and PIM They are very different: A VAVAILABILITY defines the window inside which AVAILABILITY objects take effect - it creates a block of busy time. Each AVAILABILITY object carves out a hole in that space and may be recurring or non-recurring. In addition to the recurring rules an availability might contain it also hold properties describing that availability. This is how we can specify something like Available every Monday 9am-11am in Room 303 Available every Thursday 3pm-4pm in Room 410 We can add location, or any other property we feel appropriate On 3/21/15 5:58 PM, Toby Considine wrote: A VAvailability consist of some annotation and a set of one to many Avaliabilities. Is there any difference between an Avaiability and a Recurrence? TO be specific, is this true: <!-- Properties that take a recurrence value --> < xs:element name = availability type = mpsm:RecurrenceType /> If these definitions are already in place: < xs:element name = recurrence type = mpsm:RecurrenceType /> < xs:complexType name = RecurrenceType > < xs:annotation > < xs:documentation > The Recurrence Type consists of a seed date or date-time, rules to compute compute off-sets of that seed date, an optional end or final boundary to the series, and optional exclusions, i.e., dates to be skipped. See RFC 5545 section 3.3.10 for a discussion. </ xs:documentation > </ xs:annotation > < xs:sequence > < xs:element ref = mpsm:dtStart minOccurs = 1 maxOccurs = 1 /> < xs:element ref = mpsm:rDate minOccurs = 0 maxOccurs = unbounded /> < xs:element ref = mpsm:recurrenceRule minOccurs = 1 maxOccurs = unbounded /> < xs:element ref = mpsm:exDate minOccurs = 0 maxOccurs = unbounded /> < xs:element ref = mpsm:dtEnd minOccurs = 0 maxOccurs = 1 /> </ xs:sequence > </ xs:complexType > <!-- recurrence --> < xs:element name = recurrenceRule type = mpsm:RecurrenceRuleType /> < xs:complexType name = RecurrenceRuleType > < xs:annotation > < xs:documentation > The Recurrence Rule Type is a name value pair consisting of Rule Part and Rule Values. The legal values for each Rule Part are specifed in RFC5545. There is no rule specifying the order for serializing rules; in whaterver order they appear, they must be processed in the order specified for processing rule parts in RFC5545.See RFC 5545 section 3.3.10 for a discussion. </ xs:documentation > </ xs:annotation > < xs:sequence > < xs:element ref = mpsm:recurRulePart minOccurs = 1 maxOccurs = 1 /> < xs:element ref = mpsm:recurRuleValues minOccurs = 1 maxOccurs = 1 /> </ xs:sequence ></ xs:complexType > tc “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. Toby Considine TC9, Inc.
Toby.Considine@gmail.com Phone: (919)619-2104
http://www.tc9.com Chair, OASIS OBIX Technical Committee Chair, OASIS WS-Calendar Technical Committee Editor, OASIS Energy Market Information Exchange (EMIX) Editor, OASIS Energy Interoperation blog:
http://www.NewDaedalus.com