[XML-DEV Mailing List Archive Home]
[Reply To This Message]
Namespaces and overrides
- From: "Toby Considine" <Toby.Considine@gmail.com>
- To: "xml-Dev Listserv" <firstname.lastname@example.org>
- Date: Tue, 21 Dec 2010 09:35:49 -0500
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?
"You can cut all the flowers but you cannot keep spring from coming."
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please