[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Schema WIP
Mike has been doing some great work to clean up our schemas. His methodology
has been driven by a Soap-based application to synchronize calendars between
an Exchange Server and an open source BedeWork Server
(http://www.bedework.org/bedework/). The schemas as they stand now are fully
consumeable by the usual tools, a lot clearer to read and understand, and
have greatly simplified and normalized some of the ws-calendar efforts.
The current plan is to have a single iCalendar schema when we are done. This
will be canonical, meaning none of the shortcuts and mysterious appearance
of a foreign XSD that we used in the first PR. This, in itself, will be a
great improvement.
At this stage of the WIP, we have a family of XSDs that describe the
iCalendar specification parameters, values, and properties isolated in their
own files (but part of the same schema). The Links extension is a work in
process, but will create a single property type to be used for related-to in
existing iCalendar-based applications, in ws-calendar temporal relations,
and in gluon-to-sequence relations. This normalization should simplify
programming around this specification considerably.
For now, the extensions beyond that standard used by Ws-Calendar, MS
Exchange, and BedeWorks each appear in their own files that are incorporated
into the common schema. Clearly, the proprietary MS and BW sets should not
appear in the final standard.
An aspect that is particularly nice about this approach is that the Links
and wscal extensions clearly distinguish what is fully compatible with
existing icalendar applications and what is new. Mike has proposed that the
CalConnect workplan include proposing the contents of these two back to the
IETF. Based on that, we can imagine these two extensions collapsing into the
core files for 1.1
This is still a work in progress. Comments are welcome. Soon.
tc
"If something is not worth doing, it`s not worth doing well" - Peter Drucker
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
-----Original Message-----
From: Mike Douglass [mailto:douglm@rpi.edu]
Sent: Thursday, January 06, 2011 12:42 AM
To: Considine Toby
Subject: How I changed the schema
I'll try to show this step by step as it probably affects the specification
- at least the examples might change
1. Create an extensions schema and include it in the schema 2. Drop temporal
relation stuff. Defined a link property which should cover that or more and
may end up as standard anyway (see below) 3. Defined the gap parameter as an
extension - for use with link <gap><duration>T10M</duration></gap>
4. Removed the performance stuff. Replaced wit a whole bunch of duration
type parameters (see below) 5. Gluon has been redefined as an extension of
BaseComponent 6. Dropped the default values for x-wscalendartype 7. Defined
new extension property x-wscalendar-type renamed from x-wscalendartype
As we can't define all valid components/properties/parameters in the schema
dropped any attempt to profile. Will handle by post-validation of parsed
data.
wscalendar schema disappears as a result of all this.
Added 2 extension files to the set of icalendar schema files:
iCalendar-link-extension.xsd and iCalendar-wscal-extension.xsd
We need more commenting etc on valid values. Need to define rel values for
the link.
Attached are all the files which make up the icalendar schema.
I've passed this through the wsimport tool for jaxb and no issues are
reported so I think we have something usable.
The link property
Takes a "rel" parameter with the current standard values of
"PARENT" ; Parent relationship - Default
"CHILD" ; Child relationship
"SIBLING" ; Sibling relationship
The values can be uid, uri or reference
<link>
<parameters>
<rel><text>child</text></rel?
</parameters>
<uid>12345</uid>
</link>
All we need to do is define new values for "rel". You had
<xs:enumeration value="finishtostart"/>
<xs:enumeration value="finishtofinish"/>
<xs:enumeration value="starttostart"/>
<xs:enumeration value="starttofinish"/>
We could insert them as standard values or I'd be inclined to namespace
them - some sort of urn is recommended:
urn:oasis:wscal:xml:retype:finishtostart
maybe?
------------------------------------------------
New parameters to replace performance type
<xs:element name="startbeforetolerance" type="xcal:DurationParameterType"
substitutionGroup="xcal:baseParameter" />
<xs:element name="startaftertolerance" type="xcal:DurationParameterType"
substitutionGroup="xcal:baseParameter" />
<xs:element name="endtbeforetolerance" type="xcal:DurationParameterType"
substitutionGroup="xcal:baseParameter" />
<xs:element name="endaftertolerance" type="xcal:DurationParameterType"
substitutionGroup="xcal:baseParameter" />
<xs:element name="durationlongtolerance" type="xcal:DurationParameterType"
substitutionGroup="xcal:baseParameter" />
<xs:element name="durationshorttolerance" type="xcal:DurationParameterType"
substitutionGroup="xcal:baseParameter" />
<xs:element name="granularity" type="xcal:DurationParameterType"
substitutionGroup="xcal:baseParameter" />
--
Mike Douglass douglm@rpi.edu
Senior Systems Programmer
Communication& Collaboration Technologies 518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
iCalendar-wscal-extensions.xsd
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]