[OASIS Issue Tracker] Updated: (ENERGYINTEROP-580) Additional Comments on Services Payloads

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

     [ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

William Cox updated ENERGYINTEROP-580:
--------------------------------------

    Environment: Ed Cazalet
    Description: 
NOTES INLINE IN { }

Question:  if a service is delivered to an URL ( IP address) then the payload also needs to identify the the parties to the service?  Perhaps I don't fully understand how the services will be defined.

For example, EiCreateTender should have both the TenderorPartyID and the TendereePartyIDs.  URLs may change but the PartyIDs should not. 

{Correct. the URI may resolve to an IP address but need not. PartyIDs have no specified format, only the requirement that they be expressed as strings and be unique.
}


Registration:

EiRegisterParty is just one example.  I suggest that the service be generic. EiRegister where what is registered can be a Party, EMIX Interface, Elements of an EMIX interface, EMIX MarketContext etc.  The Registrar normally will be a Party.
The purpose of registration is to assign unique IDs that may be used in different market contexts etc.

{ Correct on the purpose of registration. The reason the registration in 1.0 is "PartyRegister" or "RegisterParty" is so the more generic can be done in 1.1, or at least post 1.0. There isn't time to do a good job of generic Registration, so we've done only Party registration.
}

Enrollment:
Enrollment is Party in a MarketContext or Program (is this just a Market Context, or a sub Market Contact). Is suggest using the term EnrollAdmin instead of EnrollingParty.

{ MarketContext. Program is no longer used, but the functions and information for a "program" are in an EiMarketContext, with id emix:MarketContextType, a URI.

Accepted EnrollAdmin. We've tried to eliminate the ambiguity of "ernolling".
}

Transaction Services:

EiRequest Transaction needs Party in addition to the CounterParty and the Requestor Party.  When permitted the requester may be a regulator or another authorized party not a party to the transaction.

{as of wd32, PartyID and RequestorPartytID are mandatory, and CounterParty is optional. The semantics involve restricting the possible responses to those that include all of the stated items, so adding additional counterpartyIDs will restrict to those. Accepted in part. Good description of the intend of requestorPartyID.
}


Tender Services

I repeat my recommendation that Party and CounterParty be used instead of Tenderor and Tender.  
{ Done.
}
The use of Party and CounterParty is clear in the context of a Tender and a Transaction and this usage has been in place for over a year in the TeMIX White Paper and throughout the Ei Specification.  
{ Weak argument. A stronger one is "this is common terminology in business interactions involving agreements to buy, sell, option, and delivery.
}
In recent EI Specification drafts some UML diagrams proposed Tenderee and Tenderor but no TC consensus was attempted in my recollection.  Our terminology should be a simple as possible. 


Quote Services

I suggest the term publisherPartyID instead of quoterPartyID.
{ Accepted
}


  was:

Question:  if a service is delivered to an URL ( IP address) then the payload also needs to identify the the parties to the service?  Perhaps I don't fully understand how the services will be defined.

For example, EiCreateTender should have both the TenderorPartyID and the TendereePartyIDs.  URLs may change but the PartyIDs should not. 


Registration:

EiRegisterParty is just one example.  I suggest that the service be generic. EiRegister where what is registered can be a Party, EMIX Interface, Elements of an EMIX interface, EMIX MarketContext etc.  The Registrar normally will be a Party.
The purpose of registration is to assign unique IDs that may be used in different market contexts etc.

Enrollment:
Enrollment is Party in a MarketContext or Program (is this just a Market Context, or a sub Market Contact). Is suggest using the term EnrollAdmin instead of EnrollingParty.


Transaction Services:

EiRequest Transaction needs Party in addition to the CounterParty and the Requestor Party.  When permitted the requester may be a regulator or another authorized party not a party to the transaction.


Tender Services

I repeat my recommendation that Party and CounterParty be used instead of Tenderor and Tender.  The use of Party and CounterParty is clear in the context of a Tender and a Transaction and this usage has been in place for over a year in the TeMIX White Paper and throughout the Ei Specification.  In recent EI Specification drafts some UML diagrams proposed Tenderee and Tenderor but no TC consensus was attempted in my recollection.  Our terminology should be a simple as possible. 


Quote Services

I suggest the term publisherPartyID instead of quoterPartyID.


     Resolution: Per marked-up description. Since nearly all of the requests are addressed, resolving, applying and closing this. Further comments must be based on wd32 or later.

Thanks for the useful comments and discussions. The simplifications suggested were almost completely accepted and applied.

> Additional Comments on Services Payloads
> ----------------------------------------
>
>                 Key: ENERGYINTEROP-580
>                 URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-580
>             Project: OASIS Energy Interoperation TC
>          Issue Type: Improvement
>          Components: spec
>    Affects Versions: wd31
>         Environment: Ed Cazalet
>            Reporter: Edward Cazalet 
>            Assignee: William Cox
>             Fix For: wd32
>
>
> NOTES INLINE IN { }
> Question:  if a service is delivered to an URL ( IP address) then the payload also needs to identify the the parties to the service?  Perhaps I don't fully understand how the services will be defined.
> For example, EiCreateTender should have both the TenderorPartyID and the TendereePartyIDs.  URLs may change but the PartyIDs should not. 
> {Correct. the URI may resolve to an IP address but need not. PartyIDs have no specified format, only the requirement that they be expressed as strings and be unique.
> }
> Registration:
> EiRegisterParty is just one example.  I suggest that the service be generic. EiRegister where what is registered can be a Party, EMIX Interface, Elements of an EMIX interface, EMIX MarketContext etc.  The Registrar normally will be a Party.
> The purpose of registration is to assign unique IDs that may be used in different market contexts etc.
> { Correct on the purpose of registration. The reason the registration in 1.0 is "PartyRegister" or "RegisterParty" is so the more generic can be done in 1.1, or at least post 1.0. There isn't time to do a good job of generic Registration, so we've done only Party registration.
> }
> Enrollment:
> Enrollment is Party in a MarketContext or Program (is this just a Market Context, or a sub Market Contact). Is suggest using the term EnrollAdmin instead of EnrollingParty.
> { MarketContext. Program is no longer used, but the functions and information for a "program" are in an EiMarketContext, with id emix:MarketContextType, a URI.
> Accepted EnrollAdmin. We've tried to eliminate the ambiguity of "ernolling".
> }
> Transaction Services:
> EiRequest Transaction needs Party in addition to the CounterParty and the Requestor Party.  When permitted the requester may be a regulator or another authorized party not a party to the transaction.
> {as of wd32, PartyID and RequestorPartytID are mandatory, and CounterParty is optional. The semantics involve restricting the possible responses to those that include all of the stated items, so adding additional counterpartyIDs will restrict to those. Accepted in part. Good description of the intend of requestorPartyID.
> }
> Tender Services
> I repeat my recommendation that Party and CounterParty be used instead of Tenderor and Tender.  
> { Done.
> }
> The use of Party and CounterParty is clear in the context of a Tender and a Transaction and this usage has been in place for over a year in the TeMIX White Paper and throughout the Ei Specification.  
> { Weak argument. A stronger one is "this is common terminology in business interactions involving agreements to buy, sell, option, and delivery.
> }
> In recent EI Specification drafts some UML diagrams proposed Tenderee and Tenderor but no TC consensus was attempted in my recollection.  Our terminology should be a simple as possible. 
> Quote Services
> I suggest the term publisherPartyID instead of quoterPartyID.
> { Accepted
> }

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