[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Namespaces and overrides

  • From: "Toby Considine" <Toby.Considine@gmail.com>
  • To: "xml-Dev Listserv" <xml-dev@lists.xml.org>
  • Date: Tue, 21 Dec 2010 09:35:49 -0500

Namespaces and overrides

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."
-Pablo Neruda.

Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee


Email: Toby.Considine@g...
Phone: (919)619-2104

blog: www.NewDaedalus.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

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 click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.