[OASIS Issue Tracker] Commented: (ENERGYINTEROP-474) eiEnroll Resource Not in WD25

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28616#action_28616 ] 

Toby Considine commented on ENERGYINTEROP-474:
----------------------------------------------

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


> 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