RE: [emix] Groups - EmixPowerProducts-WD12-20101006.zip uploaded

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

Sorry to miss you.

KML is the simplest of the mapping standards. I use it during the some variants of the intrfacePricingPoint (it's either a pnode or an apnode or a serviceNode or a servicePoint or a serviceArea. The first 3 are CIM-defined, the last two are geographic and defined using KML. Some conversations suggest we should use GML instead of KML, but that is much larger and more complex. You probably know KML best as how to pin something on Google Earth.

Atom, which is a remote publish and subscribe format, is used by KML (and a lot of other standards).

EA really handles inheritance badly. If you but touch another standard, it brings in an entire other domain. I think I will have to create false stub XSDs to limit the exposure of Calendar and Map complexity to the CIM programmer.  

For example, KML describes every kind of 3D object as well. We clearly do not need all that brought in-but EA does. The KML Placemark, one of the simpler KML objects, is either a  point or polygon or combination of polygons. Polygons are just points for which you connect the dots. Since KML is a full blown map description language, polygons can also be describes as having colors or gradients or backgrounds. 

Emergency Management mapping is based upon shape servers, in which, say, a server is assigned satellite telemetry processing, and it serves up the shapes for display on dispatcher maps. Another shape server might be serving up weather or drought shapes in real time. The serious complexity of underlying systems is hidden by the shapes. Accordingly, there are freely available ways to ask shapes questions (is my point in that shape) which supports some interesting use cases in price broadcasting, et al. 

Now we can control the spread of complexity by conforming out a lot of stuff. Clearly the colors and shapes and other polygon and point display features have no place in a price communication. But I don't know how to direct EA to ignore the non-conforming portions of KML.

A similar few paragraphs could be written about Atom and about ICalendar. 

This creates some apparent complexity where there is none. EA is like Bubba Gump; we have asked about a single shrimp, and he is reciting every way to make shrimp......It is a predictable hazard of letting a tool do your thinking for you.

I think the answer is stub XSDs to make the EA diagrams simple. It means that the examples in the document will be simplified (OK they are non-normative), it will make the EA diagrams easier to look at (OK, they, to, are non-normative) and the only XSDs that we will normatively include in the spec are the EMIX and Power objects.

So let's get to the EMIX and Power Objects. 

We have a an EMIX envelope - not yet defined, but really very simple.
On the face of the Envelope we have a Product object and its associated Intervals. We have the Power Product in last night's work, but it could ship any  time-dependent product. We also have a Transmission Object defined.

Inside the Envelope, we have the Warrants, objects not yet defined. These include PowerQuality (Already defined in CIM terms. But no Artifact yet). We have an environmental Warrant (Use the EIS object, already defined in CIM terms). We probably need some sort of sample market or regulatory template.

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


-----Original Message-----
From: Ed Cazalet [mailto:ed@cazalet.com] 
Sent: Wednesday, October 06, 2010 11:45 PM
To: Considine, Toby (Campus Services IT); wtcox@CoxSoftwareArchitects.com
Subject: RE: [emix] Groups - EmixPowerProducts-WD12-20101006.zip uploaded

Toby,

What am I missing?  I can't figure out how to drop Power into EA to get it to explode.

I am also having difficulty understanding the inheritance and how to control it.

I don't know what a KML and atom are and why I need to know in order to define intervals.

Unless all of this calendar complexity be made very clear or hidden, it will be tough to get people to use it.

Glad to see power and energy are better handled here.  Still some work do here - we should talk.

Not sure why buyer and seller are in power when this is about products.  However, I also do not see where an offer and transaction that would identify a buyer and seller would be found.

The full requirements contracts with demand charge is not correct.  The demand charge is not invoked what a given amount of energy under the contract is reached.  Rather under a full requirements contract for a month for example, the maximum demand is measured by the highest average power delivered over a 15 min interval.  I have mentioned this several times and the correction keeps getting lost.

Would you be available to chat before the call tomorrow?

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: Wednesday, October 06, 2010 1:28 PM
To: emix@lists.oasis-open.org
Subject: [emix] Groups - EmixPowerProducts-WD12-20101006.zip uploaded

Updating work from Monday

 -- Toby Considine

The document named EmixPowerProducts-WD12-20101006.zip has been submitted by Toby Considine to the OASIS Energy Market Information Exchange (eMIX) TC document repository.

Document Description:
Updated to make better use if CIM names and of inheritance.

Power is core object, with an XSD for each dependent namespace. Dropping into EA explodes when it sees icalendar, xcalendar, KML, and atom.

Using Ed's Taxonomy of Products

Ancilary.xsd - Ancillary Servcices
PowerContract.xsd Power contracts, including full requirements Resource.xsd - generation and DR Transactive.xsd - Transactive Energy products Transport.XSD - Transmission and Distribution

And 

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

Download Document:  
http://www.oasis-open.org/committees/download.php/39687/EmixPowerProducts-WD12-20101006.zip


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