Notes on Icalendar Schemas and transactional restrictions

["Toby Considine" <Toby.Considine@gmail.com>]

No one took very good notes at today’s meeting.  As requested, here are some paragraphs with my spin on the core

 

The WS-Calendar specification, soon finishing its second public review, is semantically rich and supports lots of historical complexity while being designed for further extensibility. It is readily backward compatible with all existing calendar applications. The remaining problem is that this optionality, this diversity, can make it difficult to validate information exchanges for specific purposes. Today in meeting, we discussed the approaches to developing profiles of WS-Calendar for use in specific interfaces, say, those between enterprise and building systems, or in high-speed transactions such as in smart market interactions.

 

The iCalendar specification itself is only loosely bound with minimal validations. A structural validation of the incoming XML is not enough to assure its suitability for a particular purpose. Additional code is required to augment schema checks with additional required validations. These validations serve to prevent errors when the data is received by applications or components that expect the information to comply with business content validation rules. If the validation rules are written in code, they are likely to be inside the application. Rules in the application are less likely to be shared. We need common, shared validation rules.

 

We have three approaches on the table.

 

In one approach, we declare the work, with all its optionality, to date to be a Platform Specific Model (PSM). Underlying this PSM is a not yet defined Platform Independent Model (PIM). The PIM defines minimal information exchanges that must be common to all conforming specifications. The PIM and the PSM are both expressed in UML, and through the UML, we can recognize the alignments we need to define simple XML transformations (XSLT) between PIM-compliant exchanges. Bill Cox has been exploring this approach.

 

Another approach is to build on Content Assembly Mechanisms (CAM) to define a schema dictionary that defines the restrictions. CAM can then create the schemas we need from merging the application and the base or full schema. This is yet another application, but it is open source and the approach is being standardized in OASIS and on SourceForge.

 

Yet another approach is the profiling done by GML to restrict geospatial schemas for individual spaces. This appears to use some sort of substitution schema files, but I cannot say whether that is all they are doing.

 

Several folks on the call have their own views as to what the schemas might be for their own spaces.  I have included one of my own (that I sent to the list earlier) to get conversations started. Send them in!

 

Thanks

 

tc

---

“The single biggest problem in communication is the illusion that it has taken place.”
– George Bernard Shaw.

---

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

 

 

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:ts="tscalendar-wip" xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0" targetNamespace="tscalendar-wip" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:import namespace="urn:ietf:params:xml:ns:icalendar-2.0" schemaLocation="file:///C:/Users/tobias/Documents/Committees%20&amp;%20Standards/WSCalendar/Artifacts/CSD04%20WIP/iCalendar-wscal-extensions.xsd"/>
	<!--	<xs:annotation>
		<xs:appinfo source="http://schemas.opengis.net/gml/3.2.1/profiles/gmlsfProfile/2.0/gmlsfLevels.xsd";>
			<gmlsf:ComplianceLevel>0</gmlsf:ComplianceLevel>
			<gmlsf:GMLProfileSchema>http://schemas.opengis.net/gml/3.2.1/profiles/gmlsfProfile/2.0/gmlsf.xsd</gmlsf:GMLProfileSchema>
		</xs:appinfo>
	</xs:annotation>-->
	<xs:complexType name="interval" mixed="false">
				<xs:sequence>
					<xs:element ref="ts:properties" minOccurs="1" maxOccurs="1"/>
					<xs:element name="components" type="xcal:ArrayOfComponents"/>
				</xs:sequence>
	</xs:complexType>
	<xs:complexType name="wsCalendarGluonType" mixed="false">
				<xs:sequence>
					<xs:element ref="ts:properties" minOccurs="1" maxOccurs="1"/>
					<xs:element name="components" type="xcal:ArrayOfComponents"/>
				</xs:sequence>
	</xs:complexType>
	<xs:element name="properties" type="ts:PropertiesType"/>
	<xs:complexType name="PropertiesType" mixed="false">
		<xs:sequence>
			<xs:element ref="xcal:uid"/>
			<xs:element ref="xcal:dtstart"/>
			<xs:element ref="xcal:duration"/>
			<xs:element ref="xcal:x-wsCalendar-attach"/>
		</xs:sequence>
	</xs:complexType>
	<xs:element name="wsCalendarAttach" type="ts:WsCalendarAttachType"/>
	<xs:complexType name="WsCalendarAttachType" mixed="false">
		<xs:annotation>
			<xs:documentation>types the content of the xCal attach element</xs:documentation>
		</xs:annotation>
		<xs:sequence>
			<xs:element name="properties">
				<xs:complexType>
					<xs:sequence minOccurs="0" maxOccurs="1">
						<xs:element ref="xcal:startbeforetolerance"/>
						<xs:element ref="xcal:startaftertolerance"/>
						<xs:element ref="xcal:endtbeforetolerance"/>
						<xs:element ref="xcal:endaftertolerance"/>
						<xs:element ref="xcal:durationlongtolerance"/>
						<xs:element ref="xcal:durationshorttolerance"/>
						<xs:element ref="xcal:granularity"/>
					</xs:sequence>
				</xs:complexType>
			</xs:element>
			<xs:element ref="xcal:artifactBase" minOccurs="0" maxOccurs="unbounded"/>
		</xs:sequence>
	</xs:complexType>
</xs:schema>