OASIS Energy Interoperation TC

 View Only
Expand all | Collapse all

Squeezing the Message

  • 1.  Squeezing the Message

    Posted 06-27-2011 13:40
      |   view attached
    Ahh, so often when I clean out the pantry, I first make the mess worse, by taking everything out of the cabinets, cluttering all counters with ad hoc piles, and finally discover a new order as I put things back in. Until recently, The specifications that compose Energy Interoperation were all out on the counters, and the bloat was large.   Specific fixes for the OpenADR Bloat   1)       WS-Calendar is tighter than it was. Intervals no long contain components. These changes were small, but the cumulative effect over many Intervals is large. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd04/ws-calendar-spec-v1.0-csd04.html 2)       EMIX (voted out for Public Review last week) includes some specific rules for using inheritance as defined in WS-Calendar to reduce the repetition in an EMIX Schedule. (AN EMIX Schedule is defined as a Product Description applied to a WS-Calendar Sequence). In particular,  the conformance section describes how elements such as Product Description, Terms, and Time Zone can be defined once in the Standard Terms associated with a Market Context, and be inherited by all Intervals. http://www.oasis-open.org/committees/download.php/42662/emix-1-0-wd35.zip 3)       The attached document is a * rough * first draft at extending the inheritance and processing rules in EMIX and WS-Calendar into Energy Interoperation. It assumes that Program Definitions can be added to Market Contexts as if they were Product Descriptions to accomplish the same message reduction for Program-Based signals.   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     Conformance and Processing Rules for Energy Interoperation I.pdf


  • 2.  RE: [energyinterop] Squeezing the Message

    Posted 06-27-2011 15:32
    I think we have to go beyond what is specified in EMIX.  When can we get the next version of the EI schema so we can make sure we can generate the XML we agreed upon last week and generate our EI conformance statements around that.     Thanks,   -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 6:39 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] Squeezing the Message   Ahh, so often when I clean out the pantry, I first make the mess worse, by taking everything out of the cabinets, cluttering all counters with ad hoc piles, and finally discover a new order as I put things back in. Until recently, The specifications that compose Energy Interoperation were all out on the counters, and the bloat was large.   Specific fixes for the OpenADR Bloat   1)       WS-Calendar is tighter than it was. Intervals no long contain components. These changes were small, but the cumulative effect over many Intervals is large. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd04/ws-calendar-spec-v1.0-csd04.html 2)       EMIX (voted out for Public Review last week) includes some specific rules for using inheritance as defined in WS-Calendar to reduce the repetition in an EMIX Schedule. (AN EMIX Schedule is defined as a Product Description applied to a WS-Calendar Sequence). In particular,  the conformance section describes how elements such as Product Description, Terms, and Time Zone can be defined once in the Standard Terms associated with a Market Context, and be inherited by all Intervals. http://www.oasis-open.org/committees/download.php/42662/emix-1-0-wd35.zip 3)       The attached document is a * rough * first draft at extending the inheritance and processing rules in EMIX and WS-Calendar into Energy Interoperation. It assumes that Program Definitions can be added to Market Contexts as if they were Product Descriptions to accomplish the same message reduction for Program-Based signals.   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    


  • 3.  RE: [energyinterop] Squeezing the Message

    Posted 06-27-2011 15:35
    I think (3) states that we have. Of course, more squeezing is good.   It is noteworthy that there are specific use cases where all the flexibility that comes with verbose expressions is still required. For example, it is difficult to compress tiers because you still need to include multiple highwater marks for each interval. The challenge is maintain the flexibility that we must, while allowing the vast majority of messages to get much much smaller.   tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 11:32 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think we have to go beyond what is specified in EMIX.  When can we get the next version of the EI schema so we can make sure we can generate the XML we agreed upon last week and generate our EI conformance statements around that.     Thanks,   -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 6:39 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] Squeezing the Message   Ahh, so often when I clean out the pantry, I first make the mess worse, by taking everything out of the cabinets, cluttering all counters with ad hoc piles, and finally discover a new order as I put things back in. Until recently, The specifications that compose Energy Interoperation were all out on the counters, and the bloat was large.   Specific fixes for the OpenADR Bloat   1)       WS-Calendar is tighter than it was. Intervals no long contain components. These changes were small, but the cumulative effect over many Intervals is large. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd04/ws-calendar-spec-v1.0-csd04.html 2)       EMIX (voted out for Public Review last week) includes some specific rules for using inheritance as defined in WS-Calendar to reduce the repetition in an EMIX Schedule. (AN EMIX Schedule is defined as a Product Description applied to a WS-Calendar Sequence). In particular,  the conformance section describes how elements such as Product Description, Terms, and Time Zone can be defined once in the Standard Terms associated with a Market Context, and be inherited by all Intervals. http://www.oasis-open.org/committees/download.php/42662/emix-1-0-wd35.zip 3)       The attached document is a * rough * first draft at extending the inheritance and processing rules in EMIX and WS-Calendar into Energy Interoperation. It assumes that Program Definitions can be added to Market Contexts as if they were Product Descriptions to accomplish the same message reduction for Program-Based signals.   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    


  • 4.  RE: [energyinterop] Squeezing the Message

    Posted 06-27-2011 15:38
    When can we get new versions of the schema?       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 8:35 AM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think (3) states that we have. Of course, more squeezing is good.   It is noteworthy that there are specific use cases where all the flexibility that comes with verbose expressions is still required. For example, it is difficult to compress tiers because you still need to include multiple highwater marks for each interval. The challenge is maintain the flexibility that we must, while allowing the vast majority of messages to get much much smaller.   tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 11:32 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think we have to go beyond what is specified in EMIX.  When can we get the next version of the EI schema so we can make sure we can generate the XML we agreed upon last week and generate our EI conformance statements around that.     Thanks,   -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 6:39 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] Squeezing the Message   Ahh, so often when I clean out the pantry, I first make the mess worse, by taking everything out of the cabinets, cluttering all counters with ad hoc piles, and finally discover a new order as I put things back in. Until recently, The specifications that compose Energy Interoperation were all out on the counters, and the bloat was large.   Specific fixes for the OpenADR Bloat   1)       WS-Calendar is tighter than it was. Intervals no long contain components. These changes were small, but the cumulative effect over many Intervals is large. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd04/ws-calendar-spec-v1.0-csd04.html 2)       EMIX (voted out for Public Review last week) includes some specific rules for using inheritance as defined in WS-Calendar to reduce the repetition in an EMIX Schedule. (AN EMIX Schedule is defined as a Product Description applied to a WS-Calendar Sequence). In particular,  the conformance section describes how elements such as Product Description, Terms, and Time Zone can be defined once in the Standard Terms associated with a Market Context, and be inherited by all Intervals. http://www.oasis-open.org/committees/download.php/42662/emix-1-0-wd35.zip 3)       The attached document is a * rough * first draft at extending the inheritance and processing rules in EMIX and WS-Calendar into Energy Interoperation. It assumes that Program Definitions can be added to Market Contexts as if they were Product Descriptions to accomplish the same message reduction for Program-Based signals.   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    


  • 5.  RE: [energyinterop] Squeezing the Message

    Posted 06-27-2011 15:49
    Newer than last week’s?   The change here is in conformance rules, i.e. what does and does not need to be said in each interval. We probably need (as a group) to look at standard terms and see what, if anything, we want to borrow from that for the EiMarketContext, and how these two areas intersect.     The most recent schemas also made the [emix] market context string optional in the EiMarketContext. If that field is the link to standard terms, we may need to be wary of * that * optimization.   The remaining two challenges in the schema, to my eye, and I would welcome hearing from other soon, have to do with Inheritance (as a justification to compress message information) and enrollment. They go together, for if Enrollment associates and Account or Resource with a Market Context, then the information in the Standard Terms can be learned during enrollment, or re-queried on demand, and then the compression strategies start to make sense.   tc     "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 11:37 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   When can we get new versions of the schema?       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 8:35 AM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think (3) states that we have. Of course, more squeezing is good.   It is noteworthy that there are specific use cases where all the flexibility that comes with verbose expressions is still required. For example, it is difficult to compress tiers because you still need to include multiple highwater marks for each interval. The challenge is maintain the flexibility that we must, while allowing the vast majority of messages to get much much smaller.   tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 11:32 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think we have to go beyond what is specified in EMIX.  When can we get the next version of the EI schema so we can make sure we can generate the XML we agreed upon last week and generate our EI conformance statements around that.     Thanks,   -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 6:39 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] Squeezing the Message   Ahh, so often when I clean out the pantry, I first make the mess worse, by taking everything out of the cabinets, cluttering all counters with ad hoc piles, and finally discover a new order as I put things back in. Until recently, The specifications that compose Energy Interoperation were all out on the counters, and the bloat was large.   Specific fixes for the OpenADR Bloat   1)       WS-Calendar is tighter than it was. Intervals no long contain components. These changes were small, but the cumulative effect over many Intervals is large. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd04/ws-calendar-spec-v1.0-csd04.html 2)       EMIX (voted out for Public Review last week) includes some specific rules for using inheritance as defined in WS-Calendar to reduce the repetition in an EMIX Schedule. (AN EMIX Schedule is defined as a Product Description applied to a WS-Calendar Sequence). In particular,  the conformance section describes how elements such as Product Description, Terms, and Time Zone can be defined once in the Standard Terms associated with a Market Context, and be inherited by all Intervals. http://www.oasis-open.org/committees/download.php/42662/emix-1-0-wd35.zip 3)       The attached document is a * rough * first draft at extending the inheritance and processing rules in EMIX and WS-Calendar into Energy Interoperation. It assumes that Program Definitions can be added to Market Contexts as if they were Product Descriptions to accomplish the same message reduction for Program-Based signals.   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    


  • 6.  RE: [energyinterop] Squeezing the Message

    Posted 06-27-2011 16:08
    I disagree.  The changes we discussed last week do indeed require schema changes.  For example there is no way to represent price in the fashion we recommended without making a schema change. I also don’t think any of the conformance rules we discussed last week require any sort of market context since they were mainly related to rules involving WS-Calendar and how intervals are related to each other in signals. There may be other optimizations to other parts of the EI Schema that require some sort of market context, but the way we represent signals within EIEvent is not one of them.   I fear we may not be on the same page. I am confident that I can make fairly simple changes to the schema as well as the specific conformance rules that go along with those changes in order to generate the XML we agreed upon last week was desirable. I don’t think we can get there based upon what you emailed out this morning.     -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 8:48 AM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Newer than last week’s?   The change here is in conformance rules, i.e. what does and does not need to be said in each interval. We probably need (as a group) to look at standard terms and see what, if anything, we want to borrow from that for the EiMarketContext, and how these two areas intersect.     The most recent schemas also made the [emix] market context string optional in the EiMarketContext. If that field is the link to standard terms, we may need to be wary of * that * optimization.   The remaining two challenges in the schema, to my eye, and I would welcome hearing from other soon, have to do with Inheritance (as a justification to compress message information) and enrollment. They go together, for if Enrollment associates and Account or Resource with a Market Context, then the information in the Standard Terms can be learned during enrollment, or re-queried on demand, and then the compression strategies start to make sense.   tc     "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 11:37 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   When can we get new versions of the schema?       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 8:35 AM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think (3) states that we have. Of course, more squeezing is good.   It is noteworthy that there are specific use cases where all the flexibility that comes with verbose expressions is still required. For example, it is difficult to compress tiers because you still need to include multiple highwater marks for each interval. The challenge is maintain the flexibility that we must, while allowing the vast majority of messages to get much much smaller.   tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 11:32 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think we have to go beyond what is specified in EMIX.  When can we get the next version of the EI schema so we can make sure we can generate the XML we agreed upon last week and generate our EI conformance statements around that.     Thanks,   -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 6:39 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] Squeezing the Message   Ahh, so often when I clean out the pantry, I first make the mess worse, by taking everything out of the cabinets, cluttering all counters with ad hoc piles, and finally discover a new order as I put things back in. Until recently, The specifications that compose Energy Interoperation were all out on the counters, and the bloat was large.   Specific fixes for the OpenADR Bloat   1)       WS-Calendar is tighter than it was. Intervals no long contain components. These changes were small, but the cumulative effect over many Intervals is large. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd04/ws-calendar-spec-v1.0-csd04.html 2)       EMIX (voted out for Public Review last week) includes some specific rules for using inheritance as defined in WS-Calendar to reduce the repetition in an EMIX Schedule. (AN EMIX Schedule is defined as a Product Description applied to a WS-Calendar Sequence). In particular,  the conformance section describes how elements such as Product Description, Terms, and Time Zone can be defined once in the Standard Terms associated with a Market Context, and be inherited by all Intervals. http://www.oasis-open.org/committees/download.php/42662/emix-1-0-wd35.zip 3)       The attached document is a * rough * first draft at extending the inheritance and processing rules in EMIX and WS-Calendar into Energy Interoperation. It assumes that Program Definitions can be added to Market Contexts as if they were Product Descriptions to accomplish the same message reduction for Program-Based signals.   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    


  • 7.  RE: [energyinterop] Squeezing the Message

    Posted 06-27-2011 16:29
    OK   Let me generate some artifacts using these conformance rules, and look at how close they are to last week’s conversation.   -           The Market Context is just a url. -           A signal header MAY include some information that applies to each interval in a communication, obviating the need to repeat. -           A Market Context MAY be associated with Standard Terms, which MAY include TZID, Product Description (which includes units and scale, and…). If those are in the Standard Terms, then there presence in the schema can be imputed and need not be actual   The only thing that is not eliminated by that is the removal of the “Params” element   tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 12:07 PM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I disagree.  The changes we discussed last week do indeed require schema changes.  For example there is no way to represent price in the fashion we recommended without making a schema change. I also don’t think any of the conformance rules we discussed last week require any sort of market context since they were mainly related to rules involving WS-Calendar and how intervals are related to each other in signals. There may be other optimizations to other parts of the EI Schema that require some sort of market context, but the way we represent signals within EIEvent is not one of them.   I fear we may not be on the same page. I am confident that I can make fairly simple changes to the schema as well as the specific conformance rules that go along with those changes in order to generate the XML we agreed upon last week was desirable. I don’t think we can get there based upon what you emailed out this morning.     -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 8:48 AM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Newer than last week’s?   The change here is in conformance rules, i.e. what does and does not need to be said in each interval. We probably need (as a group) to look at standard terms and see what, if anything, we want to borrow from that for the EiMarketContext, and how these two areas intersect.     The most recent schemas also made the [emix] market context string optional in the EiMarketContext. If that field is the link to standard terms, we may need to be wary of * that * optimization.   The remaining two challenges in the schema, to my eye, and I would welcome hearing from other soon, have to do with Inheritance (as a justification to compress message information) and enrollment. They go together, for if Enrollment associates and Account or Resource with a Market Context, then the information in the Standard Terms can be learned during enrollment, or re-queried on demand, and then the compression strategies start to make sense.   tc     "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 11:37 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   When can we get new versions of the schema?       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 8:35 AM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think (3) states that we have. Of course, more squeezing is good.   It is noteworthy that there are specific use cases where all the flexibility that comes with verbose expressions is still required. For example, it is difficult to compress tiers because you still need to include multiple highwater marks for each interval. The challenge is maintain the flexibility that we must, while allowing the vast majority of messages to get much much smaller.   tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Monday, June 27, 2011 11:32 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   I think we have to go beyond what is specified in EMIX.  When can we get the next version of the EI schema so we can make sure we can generate the XML we agreed upon last week and generate our EI conformance statements around that.     Thanks,   -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Monday, June 27, 2011 6:39 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] Squeezing the Message   Ahh, so often when I clean out the pantry, I first make the mess worse, by taking everything out of the cabinets, cluttering all counters with ad hoc piles, and finally discover a new order as I put things back in. Until recently, The specifications that compose Energy Interoperation were all out on the counters, and the bloat was large.   Specific fixes for the OpenADR Bloat   1)       WS-Calendar is tighter than it was. Intervals no long contain components. These changes were small, but the cumulative effect over many Intervals is large. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd04/ws-calendar-spec-v1.0-csd04.html 2)       EMIX (voted out for Public Review last week) includes some specific rules for using inheritance as defined in WS-Calendar to reduce the repetition in an EMIX Schedule. (AN EMIX Schedule is defined as a Product Description applied to a WS-Calendar Sequence). In particular,  the conformance section describes how elements such as Product Description, Terms, and Time Zone can be defined once in the Standard Terms associated with a Market Context, and be inherited by all Intervals. http://www.oasis-open.org/committees/download.php/42662/emix-1-0-wd35.zip 3)       The attached document is a * rough * first draft at extending the inheritance and processing rules in EMIX and WS-Calendar into Energy Interoperation. It assumes that Program Definitions can be added to Market Contexts as if they were Product Descriptions to accomplish the same message reduction for Program-Based signals.   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    


  • 8.  RE: [energyinterop] Squeezing the Message

    Posted 06-28-2011 20:35
    Some of you contacted me off line about the Conformance statement that I sent out yesterday, and what its purpose was. Let me re-cap my understanding   1)       Last week, several of met at a working meeting at which a too-large Event Artifact was shared. On the call, we discussed some WS-Calendar elements that did not appear useful (for Event Signaling), some verbosity, and some repetition in the expression of Signal Information. Numerous times as we cut, the answer was I think I can justify that in conformance statements… 2)       As we worked * on the artifacts * we created a new artifact (by hand editing) that appeared to better meet the requirements as seen by that group 3)       Following that meeting Ed Koch shared  this hand-made artifact, validated by no schema, but looking more like we wanted it to. 4)       As a first step, I tried to see how close we could get to that w/o changing any of the schemas. My thought was the fewer changes from the normative reference, the better. Also, any conformance statements create a roadmap for transforming these artifacts back into the full ws-calendar. Is may also become desirable sometime in the future to communicate using more of the full flexibility of the WS-Calendar model. The close we remain, the easier * that * will be then. 5)       The Language I sent out (beginning of the thread with this message header) was a first pass at the conformance only. My work process is to start there, see how close I get when I run it through a code generator to an artifact generator and see what was left. 6)       The note stated “comments welcome” and “rough draft”. That is because I truly would welcome suggestions as to how to get further down that road, as well as any errors and omissions.   7)       Part of that work suggested that some improved schema definition in the area of event signal definition would help reduce payload size as well. A first draft of * those * changes is posted in the Schema work recently arrived on the OASIS site (WIP3). I welcome changes or suggestions there, as well.   8)       I am now turning to some time with the code, to see what I generate and ponder the next steps. The goal remains: artifacts similar in size and complexity to the ones Ed K posted last Thursday.     Tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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  


  • 9.  RE: [energyinterop] Squeezing the Message

    Posted 06-28-2011 21:06
      |   view attached
    Toby,   I haven’t seen your most recent schemas, but if you consult the enclosed document you will see a list of simple conformance statements and schema changes that will get us from where we started to precisely where we ended up at the end of our meeting, which is obviously where we want to get to. In short with a few very simple schema changes and a handful of simply stated conformance statements I think we can get precisely where we need to be.  These are my recommendations for how we achieve our objectives.     Thanks,   -ed Koch       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Tuesday, June 28, 2011 1:35 PM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Some of you contacted me off line about the Conformance statement that I sent out yesterday, and what its purpose was. Let me re-cap my understanding   1)       Last week, several of met at a working meeting at which a too-large Event Artifact was shared. On the call, we discussed some WS-Calendar elements that did not appear useful (for Event Signaling), some verbosity, and some repetition in the expression of Signal Information. Numerous times as we cut, the answer was I think I can justify that in conformance statements… 2)       As we worked * on the artifacts * we created a new artifact (by hand editing) that appeared to better meet the requirements as seen by that group 3)       Following that meeting Ed Koch shared  this hand-made artifact, validated by no schema, but looking more like we wanted it to. 4)       As a first step, I tried to see how close we could get to that w/o changing any of the schemas. My thought was the fewer changes from the normative reference, the better. Also, any conformance statements create a roadmap for transforming these artifacts back into the full ws-calendar. Is may also become desirable sometime in the future to communicate using more of the full flexibility of the WS-Calendar model. The close we remain, the easier * that * will be then. 5)       The Language I sent out (beginning of the thread with this message header) was a first pass at the conformance only. My work process is to start there, see how close I get when I run it through a code generator to an artifact generator and see what was left. 6)       The note stated “comments welcome” and “rough draft”. That is because I truly would welcome suggestions as to how to get further down that road, as well as any errors and omissions.   7)       Part of that work suggested that some improved schema definition in the area of event signal definition would help reduce payload size as well. A first draft of * those * changes is posted in the Schema work recently arrived on the OASIS site (WIP3). I welcome changes or suggestions there, as well.   8)       I am now turning to some time with the code, to see what I generate and ponder the next steps. The goal remains: artifacts similar in size and complexity to the ones Ed K posted last Thursday.     Tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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   Simplifications to EIEvent Signal Definitions.docx


  • 10.  RE: [energyinterop] Squeezing the Message

    Posted 06-28-2011 22:34
    Ed. You are way ahead of me. I have not consumed your conformance yet. Based upon what I posted last week, and with * no * override of the WS-Calendar schema yet. I get the following for a 4 period event.   Thoughts:   1)       Overridden WS-Calendar schema would clean up   <xcal:uid><xcal:text>001</xcal:text></xcal:uid>                 <xcal:duration><xcal:duration>PT2H</xcal:duration></xcal:duration>   The second of those is so ugly that I will comment on it during the ws-calendar public review   2)       StartDate and Time should really be in the EventSignal header (at a minimum) or in the EiEvent itself rather than in the first Interval   3)       If we use the EMIX rule of putting the TZID into the StandardTerms associated with a MarketCotnext, then the TZID vanishes from Events entirely. This might be particularly useful to meet the IRC goal of stating an OperationsDay for the beginnignn of all events.     <?xml version="1.0"?> <eitc:eiEventSignal >                 <eitc:uid>52a33376-61ca-489d-9e5b-f926940d748e</eitc:uid>                 <emix:marketContext>Context.or.Tariff.or.Program</emix:marketContext>                 <eitc:resourceID>001</eitc:resourceID>                 <eitc:signalName>Reduction Signal</eitc:signalName>                 <eitc:signalType>signalPrice</eitc:signalType>                 <xcal:vcalendar>                                 <xcal:components>                                                 <xcal:interval>                                                                 <xcal:properties>                                                                                 <xcal:uid>                                                                                                 <xcal:text>001</xcal:text>                                                                                 </xcal:uid>                                                                                 <xcal:duration>                                                                                                 <xcal:duration>PT1H</xcal:duration>                                                                                 </xcal:duration>                                                                                 <xcal:dtstart>                                                                                                 <xcal:parameters>                                                                                                                 <xcal:tzid>                                                                                                                                 <xcal:text>America/Montreal</xcal:text>                                                                                                                 </xcal:tzid>                                                                                                 </xcal:parameters>                                                                                                 <xcal:date-time>2011-05-28T13:00:00</xcal:date-time>                                                                                 </xcal:dtstart>                                                                                 <xcal:x-wsCalendar-attach>                                                                                                 <eitc:signalPrice>                                                                                                                 <emix:priceRelative>                                                                                                                                 <emix:value>0.45</emix:value>                                                                                                                 </emix:priceRelative>                                                                                                 </eitc:signalPrice>                                                                                 </xcal:x-wsCalendar-attach>                                                                 </xcal:properties>                                                 </xcal:interval>                                                 <xcal:interval>                                                                 <xcal:properties>                                                                                 <xcal:uid>                                                                                                 <xcal:text>002</xcal:text>                                                                                 </xcal:uid>                                                                                 <xcal:duration>                                                                                                 <xcal:duration>PT45M</xcal:duration>                                                                                 </xcal:duration>                                                                                 <xcal:x-wsCalendar-attach>                                                                                                 <eitc:signalPrice>                                                                                                                 <emix:priceRelative>                                                                                                                                 <emix:value>0.54</emix:value>                                                                                                                 </emix:priceRelative>                                                                                                 </eitc:signalPrice>                                                                                 </xcal:x-wsCalendar-attach>                                                                 </xcal:properties>                                                 </xcal:interval>                                                 <xcal:interval>                                                                 <xcal:properties>                                                                                 <xcal:uid>                                                                                                 <xcal:text>003</xcal:text>                                                                                 </xcal:uid>                                                                                 <xcal:duration>                                                                                                 <xcal:duration>PT30M</xcal:duration>                                                                                 </xcal:duration>                                                                                 <xcal:x-wsCalendar-attach>                                                                                                 <eitc:signalPrice>                                                                                                                 <emix:priceRelative>                                                                                                                                 <emix:value>1.03</emix:value>                                                                                                                 </emix:priceRelative>                                                                                                 </eitc:signalPrice>                                                                                 </xcal:x-wsCalendar-attach>                                                                 </xcal:properties>                                                 </xcal:interval>                                                 <xcal:interval>                                                                 <xcal:properties>                                                                                 <xcal:uid>                                                                                                 <xcal:text>004</xcal:text>                                                                                 </xcal:uid>                                                                                 <xcal:duration>                                                                                                 <xcal:duration>PT2H</xcal:duration>                                                                                 </xcal:duration>                                                                                 <xcal:x-wsCalendar-attach>                                                                                                 <eitc:signalPrice>                                                                                                                 <emix:priceRelative>                                                                                                                                 <emix:value>0.25</emix:value>                                                                                                                 </emix:priceRelative>                                                                                                 </eitc:signalPrice>                                                                                 </xcal:x-wsCalendar-attach>                                                                 </xcal:properties>                                                 </xcal:interval>                                 </xcal:components>                 </xcal:vcalendar> </eitc:eiEventSignal>     "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Tuesday, June 28, 2011 5:06 PM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Toby,   I haven’t seen your most recent schemas, but if you consult the enclosed document you will see a list of simple conformance statements and schema changes that will get us from where we started to precisely where we ended up at the end of our meeting, which is obviously where we want to get to. In short with a few very simple schema changes and a handful of simply stated conformance statements I think we can get precisely where we need to be.  These are my recommendations for how we achieve our objectives.     Thanks,   -ed Koch       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Tuesday, June 28, 2011 1:35 PM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Some of you contacted me off line about the Conformance statement that I sent out yesterday, and what its purpose was. Let me re-cap my understanding   1)       Last week, several of met at a working meeting at which a too-large Event Artifact was shared. On the call, we discussed some WS-Calendar elements that did not appear useful (for Event Signaling), some verbosity, and some repetition in the expression of Signal Information. Numerous times as we cut, the answer was I think I can justify that in conformance statements… 2)       As we worked * on the artifacts * we created a new artifact (by hand editing) that appeared to better meet the requirements as seen by that group 3)       Following that meeting Ed Koch shared  this hand-made artifact, validated by no schema, but looking more like we wanted it to. 4)       As a first step, I tried to see how close we could get to that w/o changing any of the schemas. My thought was the fewer changes from the normative reference, the better. Also, any conformance statements create a roadmap for transforming these artifacts back into the full ws-calendar. Is may also become desirable sometime in the future to communicate using more of the full flexibility of the WS-Calendar model. The close we remain, the easier * that * will be then. 5)       The Language I sent out (beginning of the thread with this message header) was a first pass at the conformance only. My work process is to start there, see how close I get when I run it through a code generator to an artifact generator and see what was left. 6)       The note stated “comments welcome” and “rough draft”. That is because I truly would welcome suggestions as to how to get further down that road, as well as any errors and omissions.   7)       Part of that work suggested that some improved schema definition in the area of event signal definition would help reduce payload size as well. A first draft of * those * changes is posted in the Schema work recently arrived on the OASIS site (WIP3). I welcome changes or suggestions there, as well.   8)       I am now turning to some time with the code, to see what I generate and ponder the next steps. The goal remains: artifacts similar in size and complexity to the ones Ed K posted last Thursday.     Tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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  


  • 11.  RE: [energyinterop] Squeezing the Message

    Posted 07-01-2011 14:28
    Well, if I were building what you propose, I would come up with               <!-- 9.9 Degenerate WS-Calendar derivatives  -->             < xs:complexType name =" proposedIntervalType " mixed =" false ">                         < xs:sequence >                                     < xs:element name =" uid " type =" xcal:UidPropType " minOccurs =" 1 " maxOccurs =" 1 "/>                                     < xs:element name =" duration " type =" xcal:DurationValueType " minOccurs =" 1 " maxOccurs =" 1 "/>                                     < xs:element ref =" eventDescriptionBase "/>                         </ xs:sequence >             </ xs:complexType >   I would put the Start Time as a mandatory element in the EventBase, defined  the first interval as the designated interval (already in the conformance rules) and make the processing of each Interval as simple as possible.   You may recall, the eventDescription hierarchy looks like:   EventDescriptionBaseType                 EventBaselineType                 SignalInformationBaseType                                 SignalReductionType                                 SignalPercentType                                 SignalLevelType                                 SignalPriceType                                 SignalMaxType   This model works fine for Signal, Baseline, and Feedback   One problem is that there is already another degenerate Interval defined as part of the EiEventScheduleType which looks like:               < xs:sequence >                         < xs:element name =" eventActivePeriod " type =" eitc:IntervalType "/>                         < xs:element name =" eventNotificationPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventRampUpPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventRecoveryPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>             </ xs:sequence >   Each of these requires some precise definitions not currently in the spec. Without those definitions, I have to speculate. The EiInterval was defined as follows.               < xs:sequence >                         < xs:element ref =" xcal:uid " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:related-to " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:dtstart " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:duration " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:x-wsCalendar-attach " minOccurs =" 0 " maxOccurs =" 1 "/>             </ xs:sequence >   Not sure what a ramp or active or recovery with no duration means.    Should these be handled as per the conformable relation processing rules we use for EventsSignals? For example: there is an implied order to the sequence of                           < xs:element name =" eventRampUpPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventActivePeriod " type =" eitc:IntervalType "/>                         < xs:element name =" eventRecoveryPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>   It begs the question as to why the cardinality of ActivePeriods can be anything from 0 to infinite. Was this intended?   Which could be handled as a normal Sequence, and push the start date into the EventSchedule as above.   You stated that you wanted to lose the WS-Calendar-Attach for Signals. This is what prevents convergence of the two models. Are these ramps special in some way, or are they actually just the same as ramp intervals (and potentially SPC201) in EMIX Resources.   If it is just EMIX resources, we can lose the special designations – its just a sequence. This would suggest that we keep the Attach for both types of intervals.   Finally, what is the eventNotificationPeriod above? Is it a way of stating “You have 10 minutes before Ramp starts and this is it”. Is it a way to skip start time on the ramp? Is it an agreement for a future time, in which case, it is better handled as an Emix Term. In Terms we have:   MinimumNotificationDuration Availability NotificationSchedule (another availability)   As it stands, we muddled semantics in the spec on hoe the EiEventScheduleType relates to the other signals. Can anyone offer a flashlight to help me through the gloom?   Thanks   tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Tuesday, June 28, 2011 5:06 PM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Toby,   I haven’t seen your most recent schemas, but if you consult the enclosed document you will see a list of simple conformance statements and schema changes that will get us from where we started to precisely where we ended up at the end of our meeting, which is obviously where we want to get to. In short with a few very simple schema changes and a handful of simply stated conformance statements I think we can get precisely where we need to be.  These are my recommendations for how we achieve our objectives.     Thanks,   -ed Koch       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Tuesday, June 28, 2011 1:35 PM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Some of you contacted me off line about the Conformance statement that I sent out yesterday, and what its purpose was. Let me re-cap my understanding   1)       Last week, several of met at a working meeting at which a too-large Event Artifact was shared. On the call, we discussed some WS-Calendar elements that did not appear useful (for Event Signaling), some verbosity, and some repetition in the expression of Signal Information. Numerous times as we cut, the answer was I think I can justify that in conformance statements… 2)       As we worked * on the artifacts * we created a new artifact (by hand editing) that appeared to better meet the requirements as seen by that group 3)       Following that meeting Ed Koch shared  this hand-made artifact, validated by no schema, but looking more like we wanted it to. 4)       As a first step, I tried to see how close we could get to that w/o changing any of the schemas. My thought was the fewer changes from the normative reference, the better. Also, any conformance statements create a roadmap for transforming these artifacts back into the full ws-calendar. Is may also become desirable sometime in the future to communicate using more of the full flexibility of the WS-Calendar model. The close we remain, the easier * that * will be then. 5)       The Language I sent out (beginning of the thread with this message header) was a first pass at the conformance only. My work process is to start there, see how close I get when I run it through a code generator to an artifact generator and see what was left. 6)       The note stated “comments welcome” and “rough draft”. That is because I truly would welcome suggestions as to how to get further down that road, as well as any errors and omissions.   7)       Part of that work suggested that some improved schema definition in the area of event signal definition would help reduce payload size as well. A first draft of * those * changes is posted in the Schema work recently arrived on the OASIS site (WIP3). I welcome changes or suggestions there, as well.   8)       I am now turning to some time with the code, to see what I generate and ponder the next steps. The goal remains: artifacts similar in size and complexity to the ones Ed K posted last Thursday.     Tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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  


  • 12.  RE: [energyinterop] Squeezing the Message

    Posted 07-01-2011 15:00
    Toby,   I think I can resolve all these issue for you.  Rather than try to describe what to do just give me the most recent version of the schemas and I will make the appropriate changes to the schemas and generate the appropriate conformance statements.     Thanks,   -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Friday, July 01, 2011 7:27 AM To: Koch, Edward; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Well, if I were building what you propose, I would come up with               <!-- 9.9 Degenerate WS-Calendar derivatives  -->             < xs:complexType name =" proposedIntervalType " mixed =" false ">                         < xs:sequence >                                     < xs:element name =" uid " type =" xcal:UidPropType " minOccurs =" 1 " maxOccurs =" 1 "/>                                     < xs:element name =" duration " type =" xcal:DurationValueType " minOccurs =" 1 " maxOccurs =" 1 "/>                                     < xs:element ref =" eventDescriptionBase "/>                         </ xs:sequence >             </ xs:complexType >   I would put the Start Time as a mandatory element in the EventBase, defined  the first interval as the designated interval (already in the conformance rules) and make the processing of each Interval as simple as possible.   You may recall, the eventDescription hierarchy looks like:   EventDescriptionBaseType                 EventBaselineType                 SignalInformationBaseType                                 SignalReductionType                                 SignalPercentType                                 SignalLevelType                                 SignalPriceType                                 SignalMaxType   This model works fine for Signal, Baseline, and Feedback   One problem is that there is already another degenerate Interval defined as part of the EiEventScheduleType which looks like:               < xs:sequence >                         < xs:element name =" eventActivePeriod " type =" eitc:IntervalType "/>                         < xs:element name =" eventNotificationPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventRampUpPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventRecoveryPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>             </ xs:sequence >   Each of these requires some precise definitions not currently in the spec. Without those definitions, I have to speculate. The EiInterval was defined as follows.               < xs:sequence >                         < xs:element ref =" xcal:uid " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:related-to " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:dtstart " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:duration " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:x-wsCalendar-attach " minOccurs =" 0 " maxOccurs =" 1 "/>             </ xs:sequence >   Not sure what a ramp or active or recovery with no duration means.    Should these be handled as per the conformable relation processing rules we use for EventsSignals? For example: there is an implied order to the sequence of                           < xs:element name =" eventRampUpPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventActivePeriod " type =" eitc:IntervalType "/>                         < xs:element name =" eventRecoveryPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>   It begs the question as to why the cardinality of ActivePeriods can be anything from 0 to infinite. Was this intended?   Which could be handled as a normal Sequence, and push the start date into the EventSchedule as above.   You stated that you wanted to lose the WS-Calendar-Attach for Signals. This is what prevents convergence of the two models. Are these ramps special in some way, or are they actually just the same as ramp intervals (and potentially SPC201) in EMIX Resources.   If it is just EMIX resources, we can lose the special designations – its just a sequence. This would suggest that we keep the Attach for both types of intervals.   Finally, what is the eventNotificationPeriod above? Is it a way of stating “You have 10 minutes before Ramp starts and this is it”. Is it a way to skip start time on the ramp? Is it an agreement for a future time, in which case, it is better handled as an Emix Term. In Terms we have:   MinimumNotificationDuration Availability NotificationSchedule (another availability)   As it stands, we muddled semantics in the spec on hoe the EiEventScheduleType relates to the other signals. Can anyone offer a flashlight to help me through the gloom?   Thanks   tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Tuesday, June 28, 2011 5:06 PM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Toby,   I haven’t seen your most recent schemas, but if you consult the enclosed document you will see a list of simple conformance statements and schema changes that will get us from where we started to precisely where we ended up at the end of our meeting, which is obviously where we want to get to. In short with a few very simple schema changes and a handful of simply stated conformance statements I think we can get precisely where we need to be.  These are my recommendations for how we achieve our objectives.     Thanks,   -ed Koch       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Tuesday, June 28, 2011 1:35 PM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Some of you contacted me off line about the Conformance statement that I sent out yesterday, and what its purpose was. Let me re-cap my understanding   1)       Last week, several of met at a working meeting at which a too-large Event Artifact was shared. On the call, we discussed some WS-Calendar elements that did not appear useful (for Event Signaling), some verbosity, and some repetition in the expression of Signal Information. Numerous times as we cut, the answer was I think I can justify that in conformance statements… 2)       As we worked * on the artifacts * we created a new artifact (by hand editing) that appeared to better meet the requirements as seen by that group 3)       Following that meeting Ed Koch shared  this hand-made artifact, validated by no schema, but looking more like we wanted it to. 4)       As a first step, I tried to see how close we could get to that w/o changing any of the schemas. My thought was the fewer changes from the normative reference, the better. Also, any conformance statements create a roadmap for transforming these artifacts back into the full ws-calendar. Is may also become desirable sometime in the future to communicate using more of the full flexibility of the WS-Calendar model. The close we remain, the easier * that * will be then. 5)       The Language I sent out (beginning of the thread with this message header) was a first pass at the conformance only. My work process is to start there, see how close I get when I run it through a code generator to an artifact generator and see what was left. 6)       The note stated “comments welcome” and “rough draft”. That is because I truly would welcome suggestions as to how to get further down that road, as well as any errors and omissions.   7)       Part of that work suggested that some improved schema definition in the area of event signal definition would help reduce payload size as well. A first draft of * those * changes is posted in the Schema work recently arrived on the OASIS site (WIP3). I welcome changes or suggestions there, as well.   8)       I am now turning to some time with the code, to see what I generate and ponder the next steps. The goal remains: artifacts similar in size and complexity to the ones Ed K posted last Thursday.     Tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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  


  • 13.  RE: [energyinterop] Squeezing the Message

    Posted 07-01-2011 15:24
    Well, but this was the hole that I ran into – we now have * two * variants on Interval, and unclear semantics around one of them.   tc   " It is the theory that decides what can be observed ."   - Albert Einstein Toby Considine Chair, OASIS oBIX Technical Committee U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC    Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Friday, July 01, 2011 11:00 AM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Toby,   I think I can resolve all these issue for you.  Rather than try to describe what to do just give me the most recent version of the schemas and I will make the appropriate changes to the schemas and generate the appropriate conformance statements.     Thanks,   -ed Koch     From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Friday, July 01, 2011 7:27 AM To: Koch, Edward; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Well, if I were building what you propose, I would come up with               <!-- 9.9 Degenerate WS-Calendar derivatives  -->             < xs:complexType name =" proposedIntervalType " mixed =" false ">                         < xs:sequence >                                     < xs:element name =" uid " type =" xcal:UidPropType " minOccurs =" 1 " maxOccurs =" 1 "/>                                     < xs:element name =" duration " type =" xcal:DurationValueType " minOccurs =" 1 " maxOccurs =" 1 "/>                                     < xs:element ref =" eventDescriptionBase "/>                         </ xs:sequence >             </ xs:complexType >   I would put the Start Time as a mandatory element in the EventBase, defined  the first interval as the designated interval (already in the conformance rules) and make the processing of each Interval as simple as possible.   You may recall, the eventDescription hierarchy looks like:   EventDescriptionBaseType                 EventBaselineType                 SignalInformationBaseType                                 SignalReductionType                                 SignalPercentType                                 SignalLevelType                                 SignalPriceType                                 SignalMaxType   This model works fine for Signal, Baseline, and Feedback   One problem is that there is already another degenerate Interval defined as part of the EiEventScheduleType which looks like:               < xs:sequence >                         < xs:element name =" eventActivePeriod " type =" eitc:IntervalType "/>                         < xs:element name =" eventNotificationPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventRampUpPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventRecoveryPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>             </ xs:sequence >   Each of these requires some precise definitions not currently in the spec. Without those definitions, I have to speculate. The EiInterval was defined as follows.               < xs:sequence >                         < xs:element ref =" xcal:uid " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:related-to " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:dtstart " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:duration " minOccurs =" 0 " maxOccurs =" 1 "/>                         < xs:element ref =" xcal:x-wsCalendar-attach " minOccurs =" 0 " maxOccurs =" 1 "/>             </ xs:sequence >   Not sure what a ramp or active or recovery with no duration means.    Should these be handled as per the conformable relation processing rules we use for EventsSignals? For example: there is an implied order to the sequence of                           < xs:element name =" eventRampUpPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>                         < xs:element name =" eventActivePeriod " type =" eitc:IntervalType "/>                         < xs:element name =" eventRecoveryPeriod " type =" eitc:IntervalType " minOccurs =" 1 "/>   It begs the question as to why the cardinality of ActivePeriods can be anything from 0 to infinite. Was this intended?   Which could be handled as a normal Sequence, and push the start date into the EventSchedule as above.   You stated that you wanted to lose the WS-Calendar-Attach for Signals. This is what prevents convergence of the two models. Are these ramps special in some way, or are they actually just the same as ramp intervals (and potentially SPC201) in EMIX Resources.   If it is just EMIX resources, we can lose the special designations – its just a sequence. This would suggest that we keep the Attach for both types of intervals.   Finally, what is the eventNotificationPeriod above? Is it a way of stating “You have 10 minutes before Ramp starts and this is it”. Is it a way to skip start time on the ramp? Is it an agreement for a future time, in which case, it is better handled as an Emix Term. In Terms we have:   MinimumNotificationDuration Availability NotificationSchedule (another availability)   As it stands, we muddled semantics in the spec on hoe the EiEventScheduleType relates to the other signals. Can anyone offer a flashlight to help me through the gloom?   Thanks   tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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     From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] Sent: Tuesday, June 28, 2011 5:06 PM To: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Toby,   I haven’t seen your most recent schemas, but if you consult the enclosed document you will see a list of simple conformance statements and schema changes that will get us from where we started to precisely where we ended up at the end of our meeting, which is obviously where we want to get to. In short with a few very simple schema changes and a handful of simply stated conformance statements I think we can get precisely where we need to be.  These are my recommendations for how we achieve our objectives.     Thanks,   -ed Koch       From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Tuesday, June 28, 2011 1:35 PM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Squeezing the Message   Some of you contacted me off line about the Conformance statement that I sent out yesterday, and what its purpose was. Let me re-cap my understanding   1)       Last week, several of met at a working meeting at which a too-large Event Artifact was shared. On the call, we discussed some WS-Calendar elements that did not appear useful (for Event Signaling), some verbosity, and some repetition in the expression of Signal Information. Numerous times as we cut, the answer was I think I can justify that in conformance statements… 2)       As we worked * on the artifacts * we created a new artifact (by hand editing) that appeared to better meet the requirements as seen by that group 3)       Following that meeting Ed Koch shared  this hand-made artifact, validated by no schema, but looking more like we wanted it to. 4)       As a first step, I tried to see how close we could get to that w/o changing any of the schemas. My thought was the fewer changes from the normative reference, the better. Also, any conformance statements create a roadmap for transforming these artifacts back into the full ws-calendar. Is may also become desirable sometime in the future to communicate using more of the full flexibility of the WS-Calendar model. The close we remain, the easier * that * will be then. 5)       The Language I sent out (beginning of the thread with this message header) was a first pass at the conformance only. My work process is to start there, see how close I get when I run it through a code generator to an artifact generator and see what was left. 6)       The note stated “comments welcome” and “rough draft”. That is because I truly would welcome suggestions as to how to get further down that road, as well as any errors and omissions.   7)       Part of that work suggested that some improved schema definition in the area of event signal definition would help reduce payload size as well. A first draft of * those * changes is posted in the Schema work recently arrived on the OASIS site (WIP3). I welcome changes or suggestions there, as well.   8)       I am now turning to some time with the code, to see what I generate and ponder the next steps. The goal remains: artifacts similar in size and complexity to the ones Ed K posted last Thursday.     Tc   "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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  


  • 14.  Re: [energyinterop] Squeezing the Message

    Posted 06-27-2011 16:06
    Toby, et al, There has to be a more simplistic mechanism of using the WS-Cal directly and extending in EI as appropriate. I think we've gone through many iterations and discussions around this same topic. This requirement will meet the original intended objective of WS-Cal/PAP 04 and its use by other standards. Thanks, -Rish On Mon, Jun 27, 2011 at 6:39 AM, Toby Considine < Toby.Considine@gmail.com > wrote: Ahh, so often when I clean out the pantry, I first make the mess worse, by taking everything out of the cabinets, cluttering all counters with ad hoc piles, and finally discover a new order as I put things back in. Until recently, The specifications that compose Energy Interoperation were all out on the counters, and the bloat was large.   Specific fixes for the OpenADR Bloat   1)       WS-Calendar is tighter than it was. Intervals no long contain components. These changes were small, but the cumulative effect over many Intervals is large. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd04/ws-calendar-spec-v1.0-csd04.html 2)       EMIX (voted out for Public Review last week) includes some specific rules for using inheritance as defined in WS-Calendar to reduce the repetition in an EMIX Schedule. (AN EMIX Schedule is defined as a Product Description applied to a WS-Calendar Sequence). In particular,  the conformance section describes how elements such as Product Description, Terms, and Time Zone can be defined once in the Standard Terms associated with a Market Context, and be inherited by all Intervals. http://www.oasis-open.org/committees/download.php/42662/emix-1-0-wd35.zip 3)       The attached document is a * rough * first draft at extending the inheritance and processing rules in EMIX and WS-Calendar into Energy Interoperation. It assumes that Program Definitions can be added to Market Contexts as if they were Product Descriptions to accomplish the same message reduction for Program-Based signals.   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     --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 GGhatikar@lbl.gov +1 510.486.6768 +1 510.486.4089 [fax] This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].