emix — archive

[Toby Considine]

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