RE: [emix] Groups - chapter3-proposal.pdf uploaded

["Considine, Toby (Campus Services IT)" <Toby.Considine@unc.edu>]

Thanks Ed

Responses below. "draft 3" had moved on some before I read this, but...


"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



-----Original Message-----
From: Ed Cazalet [mailto:ed@cazalet.com] 
Sent: Sunday, June 05, 2011 3:03 PM
To: emix@lists.oasis-open.org
Subject: RE: [emix] Groups - chapter3-proposal.pdf uploaded

Excellent Forward Progress but still some issues for me.


Line 294:
The Resource schema defines how load and generation, specific capabilities of devices and  systems to affect power and energy markets, can be described irrespective of the underlying technologies.

Rewrite as:
The Resource schema describes specific capabilities of devices and  systems, irrespective of the underlying technologies affect power and energy markets.

[Toby Considine] >>done

My view: the Power Schema must stand on its own providing all of the schema necessary for pure power transactions that to do not reflect resource capabilities.
For example retail tariffs, most financial and physical forward wholesale power trading, and TeMIX do not rely on resource capabilities and therefore should not need to use anything the Resource Schema.

[Toby Considine] Agreed

Line 306 change "exchange" to "exchanged"
[Toby Considine] Done

Line 320 and Table 3-3:
The words "or transaction" should be deleted from the description of Item Base.
[Toby Considine] Done. Now " Item does not include Quantity or Price, because a single product may have multiple quantities or prices associated with each Interval." Note: an Item is often part of a Produce Description, but is not all of it.

I suggest that the logic supporting the decision NOT to include quantity or price in the product description is questionable for the following reasons:

1. The statement in Item Base confuses multiple prices and quantities for a products that extend over several intervals with multiple prices and quantities that may be associated with a product delivered within a single interval.  For example, options have both a strike price and a premium price.  Other products may have both a demand and energy price, or an offer curve to an ISO will have a set of price quantity pairs all in each interval.
2. Other elements such as ramp rates may vary by interval and not just price or quantity.  One can imagine products with the same price and quantity in each interval of a sequence but where other elements vary, so why treat price an quantity as special.
3. Price and quantity as part of the product description can be overridden in gluons and intervals if they do vary by gluon or interval.

Therefore I can see no reason price and quantity are not part of the product description and to do otherwise only creates unnecessary confusion and potentially some unnecessary communication overhead, however minor.

[Toby Considine] 
[Toby Considine][***] I agree, but I which means I haven't written clearly enough yet. As we discussed yesterday, a Market Context can include standard terms, granularity, and even a Product Description. If the Product Description for "Real Power" is in the Gluon, we should need no more than the price/quantity in each Interval as we build the Schedule. If the Product Description for "Real Power" is in the Market Context, then it is the only legitimate Product Description for that Context, and we should be able to build a Schedule within a Product, Option, or TeMIX that has only Price and Quantity. I am still toying with the language, the conformance, and the rules to make this true whole still allowing for high-speed automated validity checking. It is this impulse which is pushing me to pull Price and Quantity out of the Product Description. I am just not sure what the new structure is yet.
[end]

Schedule defines a collection of one or more intervals with durations and starting times.  One can imagine a product applied to a schedule where nothing varies by interval.  For example, for a product for 1 MWh of energy  in each of the next 24 hours at the same price, nothing goes in the interval. Or a single interval product by definition has no elements in the interval.

While there may be a reason, there is no reason stated to require the placement of the complete product description in Components of the Schedule.  In the case of a single interval product, why can't the product description including price and quantity be communicated along with an interval with a duration and starting time based on WS-Calendar conventions?  
[Toby Considine] [See above - working toward that]
[Toby Considine] 
And in the case of multiple intervals where some product description may vary by interval or gluons, why shouldn't the only these elements be required to be in the gluons or intervals although any could be at the choice of the designers?

While great strides have been made the simplification of WS-Calendar it still introduces new concepts which we should only use were they are simpler or introduce valuable new interoperation between the grid and customer domains.

[Toby Considine] We agree on the target

Line 325 Price Base and Extensions

I think price needs to be a standalone element. Prices and price modifiers are very different elements and often used more as a control signal than a market signal.
[Toby Considine] It is always legitimate to use only the price, w/o the structure of the price optionality. We have done this in TeMIX for several revs of the spec. In those revs, the PriceBase never made it into the document, so now it appears so we can constrain it. This will be obvious (I hope) once I accomplish the changes indicated by [***] above.[end]

We can have a Price Modifier Base and Extensions for Price Relative and Price Multiplier.  Such Modifiers can apply to the price whether communicated in the product description or the market context.






 
Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los Altos, CA 94022
650-949-5274
cell: 408-621-2772
ed@cazalet.com
www.cazalet.com

-----Original Message-----
From: toby.considine@unc.edu [mailto:toby.considine@unc.edu]
Sent: Sunday, June 05, 2011 7:37 AM
To: emix@lists.oasis-open.org
Subject: [emix] Groups - chapter3-proposal.pdf uploaded

Quick Response and feedback, please!

 -- Toby Considine

The document named chapter3-proposal.pdf has been submitted by Toby Considine to the OASIS Energy Market Information Exchange (eMIX) TC document repository.

Document Description:
This is a follow on to the last comment (thanks for the replies!)

It is clear from many comments that the underlying structure of EMIX extensability is not clear. Several of the critical items are introduced at different times, and in different location. THe previous quick response
request:

http://www.oasis-open.org/apps/org/workgroup/emix/email/archives/201106/msg00066.html

suggested a mode of docuemntation for the extensibility / inheritance objects. It left our that the abstract classes from which these were all derived were not called out with sufficient clarity.

The attached rough pages, of a revised section 3, call out the base classes explicitly, define each one, and thereby provide a foundation for the appoach msg00066.



View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=42426

Download Document:  
http://www.oasis-open.org/committees/download.php/42426/chapter3-proposal.pdf


PLEASE NOTE:  If the above links do not work for you, your email application may be breaking the link into two pieces.  You may be able to copy and paste the entire link address into the address field of your web browser.

-OASIS Open Administration


---------------------------------------------------------------------
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