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
www.xtensible.net
From:
Gray, Gerald [mailto:]
Sent:
Tuesday, November 08, 2011 9:33 AM
To:
; Bartell, Bruce ;
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:
[mailto:]
On Behalf Of
Toby Considine
Sent:
Tuesday, November 08, 2011 9:29 AM
To:
' Bartell, Bruce ';
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:
Phone: (919)619-2104
http://www.tcnine.com/ blog: www.NewDaedalus.com
From:
Toby Considine [mailto: ]
Sent:
Tuesday, November 08, 2011 8:48 AM
To:
' Bartell, Bruce '; ''
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:
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;
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:
[mailto:]
On Behalf Of
Bartell, Bruce
Sent:
Tuesday, November 08, 2011 8:13 AM
To:
OASIS Issues Tracker;
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
www.xtensible.net
