I need some advice on overriding inherited schema for re-purposing. I am working on a formal definition of iCalendar.xsd to create reduce interoperation problems when performing service interactions between calendar systems. The work represents the newly updated iCalendar (now RFC 5545), and is building upon a proposed canonical XML serialization of same (http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-07) which is normatively expressed in RNC. That work is currently on a standards track in the IETF. The work also includes something we call Cal-WS which is a pure XML / WS update based upon the CalDAV work. We currently have a RESTful set of service standards, with SOAPy ones anticipated as well before the final standard. We are also extending some of the base iCalendar objects to support generic XML payloads as well as sequences of events. The goals include common operations to align behaviors and service provisions that change over time, and to allow easy interactions between domains (enterprise, markets, energy, factory operations, building systems) in which different participants have quite different expectations and “languages”, but a need to synchronize behaviors. Think of this as restaurants planning fresh peach cobbler for next June, across the domains of farms, transportation, and cooking. The work is spurred in part by the need of buildings and businesses to interact with energy markets that will grow more volatile as we add intermittent (wind, tides, sun) energy sources. So, background out of the way, here’s the question iCalendar is a very loose standard in which nearly every component, and every element of those components, is optional. As we revise, extend, “inherit” those components, we often need to make certain of their elements mandatory for some of these service interactions. What are the language / descriptive formats, preferably machine readable, that you would use to tighten specifications in this way as you adopt them for specific re-use scenarios? Thanks tc "You can cut all the flowers but you cannot keep spring from coming."
|