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

["Ed Cazalet" <ed@cazalet.com>]

I Section 3.1we begin with use of the term Actor where in a Party is an Actor in a Transactive Interaction.  A Party can be a customer, generator, retail service provider, ISO, etc.

However when we get to Section 3.2.1 An Actor is a VTN or VEN, but someone has adder "Actors or Parties" to the text which confuses.

My sense is Path 1 is best.

An Actor may be both a Party and a VEN or VTN.

An Actor in VEN/VEN interactions participates not as a Party but as a VTN or VEN.  

An Actor in Transactive interaction participates not as a VNT or VEN but as a Party.

As separate issue,  I am still confused between a Resource and a VTN in EI.  Would it not be more accurate to recognize the VTN Actor as A Resource Actor or  a Virtual Resource?  This is how Gale Horst defined it in the EPRI White Paper.  

And in his paper a VTN is a REC (Resource Energy Controller).  A REC then can be a VEN to a lower level REC and that VEN acts as a virtual resource to the REC/VTN.

This structure I think fits with the concept of a "virtual power plant" and DR as a "resource".  

In other words, if a VEN is a Resource do we need Resource as a separate construct in EI?

Note

Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los Altos, CA 94022
650-949-5274
cell: 408-621-2772
ed@cazalet.com
www.cazalet.com


-----Original Message-----
From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of OASIS Issues Tracker
Sent: Sunday, October 23, 2011 10:22 AM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] [OASIS Issue Tracker] Commented: (ENERGYINTEROP-592) Clean up inheritance and substitution in partyIDs


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

Toby Considine commented on ENERGYINTEROP-592:
----------------------------------------------

This is a new issue. Previously, partyID was abstract and all instances of PartyID named, c.f., enrolleePartyId, registreePartyID, etc. 

In this WD, we have moved agressively to adopt the Party/CounterParty terminology for transactive services with the resulting use of partyID, counterPartyID in numerous payloads.THis broke our ability to have a non-specific "partyID" in payloads (which was quite useful) as well as the ability to distinguish between a single instance of, say, counterPartyID and partyID.

Two paths are visible:

1) generic abstract version becomes "Actor", with the abstract "actorID" being used for all type-safe generic references. PartyID would then be demoted to stand alongside the other ActorID-derived types. THis would require re-writing the beginning of section 5.

2) make partyID abstract again, and use another terminology for pairs in Transactive messages, i.e., partyID and countnerPartyID. This causes problems in the type party whis currently concrete but would then have an abstract ID which would require substitution in any communication. That *might* be a good thing.

Whenever this is done, several payloads would require review to make sure their cardinality is correct.

> 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: Toby Considine
>             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

        

---------------------------------------------------------------------
To unsubscribe, e-mail: energyinterop-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: energyinterop-help@lists.oasis-open.org