OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [energyinterop] Error and short-fuse comments


Same issue we ran into. Circuit location is what we are really after.

 

Bruce Bartell

Xtensible Solutions

Mobile: +1.321.258.6500

bbartell@xtensible.net  |   www.xtensible.net

 


From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of Joshua Phillips
Sent: Tuesday, November 08, 2011 10:40 AM
To: William Cox; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Error and short-fuse comments

 

I believe 2 or 3 will be the best solution.  I don’t believe the IRC is using GML to define a resources location.  It’s a system location, so geographic information is not accurate enough.  A resource could be miles away from its actual connection point to the grid, but closer or in another geographic connection point to the grid.

 

 

 

From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of William Cox
Sent: Tuesday, November 08, 2011 9:18 AM
To: energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] Error and short-fuse comments

 

Numbers refer to the *3* routes, numbered 1 through 4 below...

I think 1 and 4 aren't candidates. They share the same problem - they focus on only the geospatial aspect of the interface. This loses the capabilities which we spent a great deal of time on, including eliminating things like service delivery point, Pnode, Apnode, etc.

The point is that emixInterface generalizes the notion of "location". And that that generalization is important.

Of 2 and 3, 2 is the simplest workaround keeping "location", and 3 is my preference.

Why would we have a "location" for BOTH the ResourceType (inherits from EnrolleeType) AND in the contained emixResource? So another choice might be to give up the word "location" and do 3 as it directly allows any emix interface.

Thanks!

bill
--

William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax


On 11/8/11 9:33 AM, Gray, Gerald wrote:

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]