[OASIS Issue Tracker] Commented: (ENERGYINTEROP-592) Clean up inheritance and substitution in partyIDs

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

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

Edward Cazalet  commented on ENERGYINTEROP-592:
-----------------------------------------------

Based on Ed K's use case in Issue 585:

PG&E is an Actor.  

For Transactive Services,  the Actor PG&E enrolls as a Party in any Transactive Market Context such as the WSCC Bilateral Market.

For a DR Program such as CPP, the Actor PG&E enrolls as a VTN in the PG&E CPP DR Program Market Context.  

EdKea, the Customer is an Actor that may enroll as a Party in any Transactive Market Contexts that may be available in some states.

EdKea the Customer is an Actor that may enroll as Actors multiple Resources in the various DR Programs available to it in its various juristictions. 

Each Resource is a VEN to the VTN for the DR Program it which it is enrolled.

Resources can be Stores or Floors in Stores as an Example.

As is convenient for EdKea, it can create EdKea private DR Programs with by creating a new VTN/VEN interaction where the VTN is a controller to a set of Resources such as floors in a store and where each floor is a Resource or VTN.  Or it may expose each Floor as a Resource (VTN) to the PG&E VTN by enrolling each Floor in teh PG&E DR CPP Program.

Yes, as Ed K says, all of this is complicated and confusing.  In the real world we deal with parties in transactive market where only the energy or capacity is transacted and where options on such may be used.  In the real world we also deal with DR programs managed by a DR Operator who manages a set of curtailment and DER resources. 

The terminology of VEN and VTN is new and we will have to see if it is useful for more than architecture.  But is is clear that we should not confuse a Party in Transactive Market with a virtual Resource in a DR market.  The Resource is not a Party.




> Clean up inheritance and substitution in partyIDs
> -------------------------------------------------
>
>                 Key: ENERGYINTEROP-592
>                 URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-592
>             Project: OASIS Energy Interoperation TC
>          Issue Type: Bug
>    Affects Versions: wd32
>         Environment: Toby Considine
>            Reporter: Toby Considine
>            Assignee: Edward Cazalet 
>             Fix For: WD33
>
>
> In current schema, all PartyIDs are derived from PartyID (implicitly through substitution group). PartyID itself was previously abstract, and now is concrete. THis periodically causes processing errors, particuarly when MinOccurs is allowed. For example:
> For example, the type EiTarget includes (abreviated)
> 		<xs:sequence>
> 			<xs:element ref="eitc:venID" minOccurs="0" maxOccurs="unbounded"/>
> 			<xs:element ref="eitc:partyID" minOccurs="0" maxOccurs="unbounded"/>
> 		</xs:sequence>
> As currently defined a venID is a PartyID, so the processor may be unable to determine whether a listed venID is one of the unbounded venIDs or the first of the unbounded partyIDs. THis only occurs because of the indeterminacy of the count of venID above. there would be no problem if, for example, venID was specified as minOccurs="1" maxOccurs="1"

-- 
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