[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Squeezing the Message
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
From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] 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 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
From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] When can we get new versions of the schema? From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine 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
From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] 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 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. 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. 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.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]