ws-calendar — archive

[William Cox]

Thanks to all present for a vigorous discussion last week (in our interim Workshop meeting) - especially to Mike for making the time to get there. I've been turning over the discussions (and subsequent emails) in my mind. I am concerned that RRules, Exdate, Rdate, and Priority unnecessarily complicate the Platform-Independent Model. I see the need, IF Vavailability is present, to include AvailabilityType with the recurrence set. I do not see a broad need for Vavailability in Gluons -- for a non-universal need this seems a major complication, with semantics that require a dozen pages in the RFCs to describe (but not thoroughly explain), and raises barriers to use. Several possibilities come to mind: (1) Clarify the optionality of the Vavailability classes (it was actually simpler to say that when it was a simple package, but the incestuous references are a compelling argument against separate package) (2) Create three conformance points:     (a) PIM Classic (without Availability, and without recurrence in Gluons) - as a PIM to the WS-Calendar PSM     (b) PIM with Availability - as a PIM to the WS-Calendar-extensions + Availability extension     (c) PIM with the whole range - WS-Calendar Extensions, Availability extension, added recurrence extensions to Gluon (2)(c) seems simpler, and satisifies the ASHRAE/NEMA SPC201 needs (without them defining their minimal PSM) as a representative of facility scheduling, all using PIM+whole range (2)(a) addresses EMIX and product design - I think that injecting recurrences into market product descriptions is much to complex. (2)(b) addresses Energy Interoperation, as it already uses D5 availability (though not as fully as we've done in the PIM WD14+) Thoughts? Optionality in schemas? Perhaps an XSD each for (2) a, b, and c? Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile