XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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?

 

Thanks

 

tc


"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@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 



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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS