[OASIS Issue Tracker] Created: (ENERGYINTEROP-633) IPKeys Feedback on OpenADR Core Profile and Related Schemas

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

IPKeys Feedback on OpenADR Core Profile and Related Schemas
-----------------------------------------------------------

                 Key: ENERGYINTEROP-633
                 URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-633
             Project: OASIS Energy Interoperation TC
          Issue Type: Improvement
    Affects Versions: wd30
         Environment: IPKeys Bill Walker
            Reporter: Toby Considine
            Assignee: William Cox
            Priority: Minor


In reviewing the EI schemas relating to the OpenADR profile, we have identified areas that we believe could be   optimized for exchange of messages with end point devices. This document also addresses items related to practical implementations. Our feedback addresses the following areas:

1.	Redundancy in element naming and the use of attributes versus elements.
2.	Deeply nested structures. 
3.	Use of general purpose scheduling (WS-Calender) in a core profile where only intervals, sequences, and durations are required. 

The feedback is directed not at the semantics of the messages (except possibly for number 3, explained below) but the way some of the elements are structured. The first priority is the semantics of the problem domain, followed by the structural representation of messages. We believe that a more efficient structure is possible. Our definition of efficiency pertains not just to packet size, but more widely to:

1.	Network bandwidth, memory, and CPU processing related to message size and structure.
2.	Human readability of messages. This is extremely important to developers, testers, and engineers who need to design test data and monitor and troubleshoot network traces, and server message logs.
3.	The structure of programs that must consume these messages. The sole purpose of Web services is to support program to program communication. Developers use standard tools like JAXB and XML parsers to represent message content inside programs. Any decisions made regarding message structure must seriously consider the impact on the end-consumer, the program, with regard to code development and maintenance. 

It turns out that much of this concern is directed at RFC-6321 (xCal) upon which WS-Calendar is based. The original iCalendar spec defined components, properties, parameters, and values. It appears that xCal chose to nest properties and components. The iCalendar components could simply be top level elements, and properties applying to individual elements could be child elements. Furthermore, xCal chose elements for where attributes would be more appropriate (uid) and unnecessary elements (text). 

Here is an example from the xCal specification representing an iCalendar VEVENT:

<?xml version="1.0" encoding="UTF-8"?>
<vevent>
    <properties>
        <dtstamp>
            <date-time>2006-02-06T00:11:21Z</date-time>
        </dtstamp>
        <dtstart>
            <parameters>
                <tzid>
                    <text>US/Eastern</text>
                </tzid>
            </parameters>
            <date-time>2006-01-04T14:00:00</date-time>
        </dtstart>
        <duration>
            <duration>PT1H</duration>
        </duration>
        <recurrence-id>
            <parameters>
                <tzid>
                    <text>US/Eastern</text>
                </tzid>
            </parameters>
            <date-time>2006-01-04T12:00:00</date-time>
        </recurrence-id>
        <summary>
            <text>Event #2 bis</text>
        </summary>
        <uid>
            <text>00959BC664CA650E933C892C@example.com</text>
        </uid>
    </properties>
</vevent>

A more efficient representation would be: 

<vevent uid="00959BC664CA650E933C892C@example.com">
    <dtstamp type="date-time">2006-02-06T00:11:21Z</dtstamp>
    <dtstart tzid="US/Eastern" type="date-time">2006-01-04T14:00:00</dtstart>
    <duration>PT1H</duration>
    <recurrence-id tzid="US/Eastern" type="date-time">2006-01-04T12:00:00</recurrence-id>
    <summary>Event #2 bis</summary>
</vevent>

Here is another example from the WS-Calendar specification describing a single interval, with a start time and duration:

<xcal:interval>
	<xcal:properties>
		<xcal:uid>
			<xcal:text>bfe8069a-0c94-4b53-852f-6a2f12639c7e</xcal:text>
		</xcal:uid>
		<xcal:duration>
			<xcal:duration>PT10H</xcal:duration>
		</xcal:duration>
	</xcal:properties>
</xcal:interval>

This could be expressed directly as a single element:

<xcal:interval xcal:uid="bfe8069a-0c94-4b53-852f-6a2f12639c7e" ical:duration="PT10H"/>

Clearly the uid is metadata, and best-practices indicate that it should be an attribute, not an element. One could argue that duration could be represented as a child element, in which case this would be:

<xcal:interval xcal:uid="bfe8069a-0c94-4b53-852f-6a2f12639c7e">
    <xcal:duration>PT10H</xcal:duration>
</xcal:interval>

We still prefer the first representation, as durations are simple iCalendar strings and will not contain other structured information. They can be applied to other elements including the event itself.  



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira