We deliberately shied away from any sort of standard customizations / typing of gml Abstract Features for EMIX 1.0. Most standard that use GML defined careful profiles. For example, some profiles of abstract features use straight lines only, but define in the type that anything within a buffer range of 50 meters is “on that line”. In watershed management, riparian buffers are defined as anything within x feet of the flood water boundary of the stream or river. These profiles are instantiated as concrete types derived from the abstract type, in this case, the abstract feature type. The knowledge embedded in such rules becomes a part and parcel of every map that uses those feature types. The regulatory worlds of land-use are driven by these special purpose types. Riparian buffers, wetlands, commercial set-backs, special tax regions, school zones, are all defined in this manner, and then applied automatically to the maps. This type of feature definition is at the heart of how GIS is different than CAD, and most users of GML use this sort of standard definition. I can easily imagine an extension schema to EMIX, whether developed within OASIS or without, that extends the abstract Service Area type (a sub-type of Emix Interface) to define neighborhoods, regions, jurisdictions, distribution zones, special power usage areas…and that these zones could have economic or regulatory aspects. During the development of EMIX, the focus was on creating an extensible framework to support these special cases, without spending the time to mandate them before anyone was ready to. It is my belief that IRC members, utilities, coops, transmission operators, would all (or each) be able to find value with this sort of extension, and that if any such extension arrive, they would almost immediately be a component of enrolling DER. That is the argument for using the EMIX Interface abstraction for GML (the Service Area). Another model for DER might be that it is all managed reference to particular infrastructure. In particular, I can easily imagine a future business process in which the key enrollment question might be “What Sub-station will you connect it to?”. Similarly, it might be “build it in the desert, and what Transmission Node will it connect to?” In either of those cases, it would be essential be able to use the other types of Emix Interface. While I tried to represent the pros and cons dispassionately in starting this thread, my vote is for Item 3 with appropriate annotation. tc "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery 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:
energyinterop@lists.oasis-open.org [mailto:
energyinterop@lists.oasis-open.org] On Behalf Of Bartell, Bruce Sent: Tuesday, November 08, 2011 10:08 AM To: Gray, Gerald;
Toby.Considine@gmail.com;
energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Error and short-fuse comments What? Go next door without walking around the block? The requirement is that the resource can provide, as part of the enrollment process, whatever location information that can be targeted in an event. I would imagine that the resource has a gml point location and would know if it is inside a polygon target. I don’t know what we need to get to do that. Bruce Bartell Xtensible Solutions Mobile: +1.321.258.6500
bbartell@xtensible.net www.xtensible.net From: Gray, Gerald [mailto:
ggray@epri.com] Sent: Tuesday, November 08, 2011 9:33 AM To:
Toby.Considine@gmail.com; Bartell, Bruce;
energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Error and short-fuse comments My preference is to reference GML directly. Good development of the pros/cons Toby, however, on balance I come down on the side of referencing GML directly. Referencing GML directly, if it diverges, is a single order of divergence. Referencing GML via EMIX, if there is divergence, potentially creates two orders of divergence. From:
energyinterop@lists.oasis-open.org [mailto:
energyinterop@lists.oasis-open.org] On Behalf Of Toby Considine Sent: Tuesday, November 08, 2011 9:29 AM To: 'Bartell, Bruce';
energyinterop@lists.oasis-open.org Subject: [energyinterop] Error and short-fuse comments Ok, Bruce has zoomed in on an unexpected feature of XML. This feature breaks the Resource location. See below for thread. The abstract type is inherited properly. It breaks the substitution group rules, though. To recap: <type name =”fooType” abstract=”true”> <element name=”foo” type=”fooType” > <type name =”fooType” abstract=”true”> <element name=”notFoo” type=”fooType” > <xs:element name="fooFighter" type="emix:fooFighterType" substitutionGroup="foo"/> <type name =”fooFighterType” > <xs:extension base="fooType"/> </type> <xs:element name="fooLover" type=" fooLoverType " substitutionGroup="foo"/> <type name =”fooLoverType” > <xs:extension base="fooType"/> </type> fooFIghter and fooLover are substitutes for foo fooFIghter and fooLover are NOT substitutes for notFoo We have three routes we can go. (1) WE can make location a name (or reference) to an existing concrete type, (2) we can make location a container for an EMix Interface (3) We can simply stick an EMix Interface in there can get rid of the word Location. (4) We can lose the entire EMIX stuff and refer to the GML directly Discussion: 1) Location is all that matters, we don’t care about any of the other possible meaning of interface, we want a geographic location only. The counter-argument is that what matters may well be “what substation is this resource attaching to” which is covered by the interface but not by the location <element name="location" type="emix:ServiceAreaType"/> 2) If we just put an Emix Interface there, no one will understand it. The word and concept Location is important, especially since a Resource, could, in concept, be a collection of [devices] each with its own EMIX Interface. <element name="location" type="locationType> <type ="locationType> <element ref= "emix:emixInterface"/> </type> 3) Emix defined it. Add an annotation and be done with it. THe other interfaces (see 2) will be embedded inside emix:resources anyway, so why worry about it. <element name="emixInterface" type="emix:EmixInterfaceType"/> 4) We can lose the entire EMIX stuff and refer to the GML directly. It is just confusing to reference that EMIX stuff. There would be no issue if we went directly to the GML. Well, we would have to include the gml profile defintions stuff, and it could, in concept, diverge from the normalization of GML performed in EMIX. The down-side is that if a future version of emix defines standard gml profiles for, say “within 50 feet of a Transmission line” or “distribution zone associated with a sub-station” we will not inherit them. <element name="location" type="gml:AbstractFeature"/> Please discuss and vote tc "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery 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: Toby Considine [mailto:
Toby.Considine@gmail.com] Sent: Tuesday, November 08, 2011 8:48 AM To: 'Bartell, Bruce'; '
energyinterop@lists.oasis-open.org' Subject: RE: [energyinterop] [OASIS Issue Tracker] Commented: (ENERGYINTEROP-474) eiEnroll Resource Not in WD25 OK, I see the symptom in xmlspy schema view. Not sure why, though. Let me poke around further. tc "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery 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: Considine, Toby (Campus Services IT) Sent: Tuesday, November 08, 2011 8:45 AM To: 'Bartell, Bruce'; OASIS Issues Tracker;
energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] [OASIS Issue Tracker] Commented: (ENERGYINTEROP-474) eiEnroll Resource Not in WD25 Not sure what is going on there. I will wiggle the parts and see if something squeaks. EMixInterface is, of course, abstract. It relies either on inclusion of gml schemas (for spatial references) or EMIX Power schemas (for node/meter/etc references). Any chance those are not being resolved properly? 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:
energyinterop@lists.oasis-open.org [mailto:
energyinterop@lists.oasis-open.org] On Behalf Of Bartell, Bruce Sent: Tuesday, November 08, 2011 8:13 AM To: OASIS Issues Tracker;
energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] [OASIS Issue Tracker] Commented: (ENERGYINTEROP-474) eiEnroll Resource Not in WD25 The type shows up in the latest version, but I have to resolve it manually. Bruce Bartell Xtensible Solutions Mobile: +1.321.258.6500
bbartell@xtensible.net www.xtensible.net
Original Message----- From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of OASIS Issues Tracker Sent: Monday, November 07, 2011 8:45 PM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] [OASIS Issue Tracker] Commented: (ENERGYINTEROP-474) eiEnroll Resource Not in WD25 [ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28606#action_28606 ] Toby Considine commented on ENERGYINTEROP-474: ---------------------------------------------- Location is an EMix Interface... <xs:element name="location" type="emix:EmixInterfaceType" minOccurs="1" maxOccurs="1"/> > eiEnroll Resource Not in WD25 > ----------------------------- > > Key: ENERGYINTEROP-474 > URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-474 > Project: OASIS Energy Interoperation TC > Issue Type: Improvement > Components: spec > Affects Versions: wd25 > Environment: Bartell > Reporter: Bruce Bartell > Assignee: Toby Considine > Fix For: wd34 > > > The enrollment services are not in wd25 in spec or schema payloads. > Is this going to be in CD02? or later? > I am assuming that this is where the resoruce "capabilities and constraints" will be defined. > Capabilities as what can be shed/generate over time (ramps) and contraints as min/max per # items that were already defined for resoruces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: energyinterop-unsubscribe@lists.oasis-open.org For additional commands, e-mail: energyinterop-help@lists.oasis-open.org