[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (ENERGYINTEROP-633) IPKeys Feedback on OpenADR Core Profile and Related Schemas
[ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28510#action_28510 ]
Girish Ghatikar commented on ENERGYINTEROP-633:
------------------------------------------------
As per our TC discussions yesterday, I looked at this proposal in detail and discussed with Bill Walker of IPKeys (the original proposer). The proposal is as follows:
Add two new elements, with the exact same semantics but different names in the OpenADR profile namespace. These elements would could use iCalendar durations and ISO 8601 timestamps to represent the intervals. They would still express the durations, signal values, types, and current values. It will look something like this:
<nsX:eiActiveInterval dtstart="text" duration="text">
<nsX:notification duration="text" />
<nsX:rampUp duration="text"/>
<nsX:recovery duration="text"/>
<nsX:intervalValue duration="text"></nsX:intervalValue>
</nsX:eiActiveInterval>
<nsX:signalIntervals
<nsX:signalInterval signalType="level" signalName="SIMPLE" duration="P2H">
<nxX:currentQuantity>currentValue</nxX:currentQuantity>
<nxX:quantity>valueDuringInterval</nxX:quantity>value</nxX:value>
</nsX:signalInterval>
</nsX:signalIntervals>
Which would be used to represent the current form:
<ns1:eiActivePeriod>
<ns1:components>
<ns1:interval>
<ns1:properties>
<ns1:dtstart>
<ns1:date-time>text</ns1:date-time>
</ns1:dtstart>
<ns1:duration>
<ns1:duration>text</ns1:duration>
</ns1:duration>
<ns1:x-eiNotification>
<ns1:duration>text</ns1:duration>
</ns1:x-eiNotification>
<ns1:x-eiRampUp>
<ns1:duration>text</ns1:duration>
</ns1:x-eiRampUp>
<ns1:x-eiRecovery>
<ns1:duration>text</ns1:duration>
</ns1:x-eiRecovery>
</ns1:properties>
</ns1:interval>
</ns1:components>
</ns1:eiActivePeriod>
<ns1:eiEventSignals>
<ns1:eiEventSignal ns1:schemaVersion="text">
<ns1:intervals>
<ns1:Interval>
<ns1:uid>
<ns1:text>text</ns1:text>
</ns1:uid>
<ns1:duration>
<ns1:duration>text</ns1:duration>
</ns1:duration>
<ns1:signalPayload>
<ns1:payloadQuantity>
<ns1:quantity>text</ns1:quantity>
</ns1:payloadQuantity>
</ns1:signalPayload>
</ns1:Interval>
</ns1:intervals>
<ns1:signalName>text</ns1:signalName>
<ns1:signalType>text</ns1:signalType>
<ns1:signalID>text</ns1:signalID>
<ns1:currentValue>
<ns1:payloadQuantity>
<ns1:quantity>text</ns1:quantity>
</ns1:payloadQuantity>
</ns1:currentValue>
</ns1:eiEventSignal>
</ns1:eiEventSignals>
At this point -- the final proposal is to optimize the schema without compromising the timeline. The timeline issue comes if the proposed solution is not compliant to WS-Cal schema (which is not the intention). In this event, this proposal (or part of it) must be included for consideration (with explicit mention) post EI 1.0.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]