[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (ENERGYINTEROP-443) 745: Section 5.4is VEN/VTN centric
[ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
William Cox updated ENERGYINTEROP-443:
--------------------------------------
Proposal:
From Ed Cazalet, edited by Bill Cox: I went back to Resource with its possible confusions, because "Account" would take a significant amoujnt of reword to be usable for PR02. Those aspects should be considered post PR02.
Suggeest revising the part of 5.4 that refers to both transactive and VEN/VTN as follows:
5.4 Narrative Framework for EI Services (Non-Normative)
The summary that follows provides a narrative guide to aid in understanding key potential uses of the services. It does not define a normative market or application framework. Markets and applications may use some or all of the services defined in this specification.
A Party first establishes a unique Party ID.
A Party may also Enroll (using EiEnroll) various Resources with respect to its Party ID and in a specific EiMarketContext. A Resource can be enrolled in one or more Market Contexts. A Market Context may include specific Terms. . Market and application rules concerning multiple enrollments are out of scope for this specification.
A Party registers with another Party and exchanges Party IDs. Registration establishes an identity and basic contact information. [does it do the latter? That's EiEnroll I think]
A Party may create one or more Market Contexts (out of the scope of this specification) or refer to Market Contexts defined by others.
A Party may request information from another Party about about the Market Contexts that either may support or use.
Parties may then register Resources with each other for transactions in mutually agreed Market Contexts.
Parties may also register with a Market Context to expose their interests to other parties. [??]
For transactive services Parties may interact with service operations expressing indications of interest, tenders, transactions, deliveries, and publication of information to each other and to others.
[NOTE FROM ED]
The material below would extend the framework to cover VTN/VEN. However, the material below still needs substantial rework to make sense.
[NOTE FROM BILL]
This might be a good place for the Transactive State transition diagrams and text if not placed in section 3 or 4.
To act as a VEN, a Party may locate one or more potential VTNs by any means, by search in a Market Context or by polling a potential VTN for the Market Contexts that it offers.
One or more parties may offer to serve as a VTN or as a VEN. Some market MAY have only one potential VTN. Some Parties MAY be constrained to acting solely in the VEN role. Any such market rule and set of roles is outside the scope for this specification.
A Party which wishes to act as a VEN enrolls one or more Accounts with a VTN. During enrollment, an Account is associated a particular market context. An Account may be enrolled as a Resource, and exchange detailed capability information, or it may be enrolled solely as a transactive participant. A VEN can choose to enroll a single Account in multiple market contexts, or with multiple VTNs. An Account enrolled in a Market Context accepts the rules of that Market Context, which may include specific Terms including non-performance penalties. Market and Application rules concerning multiple enrollments a
out of scope for this specification.
A VEN identifies its Accounts by Party ID (its own) and Account Name. It is possible to enroll an Account and associate it with no Market Context. The meaning of such an enrollment is determined by market rules which are outside the scope of this specification.
During Enrollment, each Account is associated with one or more schedules. A Market Context may have a schedule for when it is active. An Account may have a schedule when it can respond to requests. A market may offer different terms for day-time and night-time performance. A VEN may require different Terms for work-time and after-hours performance. Enrollment makes no statement about how suc Terms are agreed to, but only how the agreement is expressed.
A VEN may Opt to change its availability for performance. It can make permanent, i.e., non-expiring changes to its schedule by re-enrollment. It can Opt-In to add a specific availability schedule to the existing schedule for a discrete time. It may Opt-Out, replacing the current schedule with another for a discrete time.
[ Show ยป ]
Edward Cazalet added a comment - 01/Jul/11 10:31 AM Suggeest revising the part of 5.4 that refers to both transactive and VEN/VTN as follows: 5.4 Narrative Framework for EI Services (Non-Normative) The summary that follows provides a narrative guide to aid in understanding key potential uses of the services. It does not define a normative market or application framework. Markets and applications may use some or all of the services defined herein. A Party first establishes a unique Party ID. A Party may also establish one or more Accounts under its Party ID. An Account can be enrolled in one or more Market Contexts. A Market Context may include specific Terms. . Market and application rules concerning multiple enrollments are out of scope for this specification. A Party registers with another party and exchanges Party ID. Registration establishes an identity and basic contact information. A Party may create one or more Market Contexts or refer to Market Contexts defined by others. A Party may request information from a Party with which it has registered about about the Market Contexts that it supports. Parties may then register Accounts with each other for transactions in mutually agreed Market Contexts. Parties may also register with a Market Context to expose their interests to other parties. For transactive services Parties may then interact with indications of interest, tenders, transactions, deliveries, and publication of information to each other and to others. The material below would extend the framework to cover VTN/VEN. However, the material below still needs substantial rework to make sense. To act as a VEN, a Party may locate one or more potential VTNs by any means, by search in a Market Context or by polling a potential VTN for the Market Contexts that it offers. One or more parties may offer to serve as a VTN or as a VEN. Some market MAY have only one potential VTN. Some Parties MAY be constrained to acting solely in the VEN role. Any such market rule and set of roles is outside the scope for this specification. A Party which wishes to act as a VEN enrolls one or more Accounts with a VTN. During enrollment, an Account is associated a particular market context. An Account may be enrolled as a Resource, and exchange detailed capability information, or it may be enrolled solely as a transactive participant. A VEN can choose to enroll a single Account in multiple market contexts, or with multiple VTNs. An Account enrolled in a Market Context accepts the rules of that Market Context, which may include specific Terms including non-performance penalties. Market and Application rules concerning multiple enrollments a out of scope for this specification. A VEN identifies its Accounts by Party ID (its own) and Account Name. It is possible to enroll an Account and associate it with no Market Context. The meaning of such an enrollment is determined by market rules which are outside the scope of this specification. During Enrollment, each Account is associated with one or more schedules. A Market Context may have a schedule for when it is active. An Account may have a schedule when it can respond to requests. A market may offer different terms for day-time and night-time performance. A VEN may require different Terms for work-time and after-hours performance. Enrollment makes no statement about how suc Terms are agreed to, but only how the agreement is expressed. A VEN may Opt to change its availability for performance. It can make permanent, i.e., non-expiring changes to its schedule by re-enrollment. It can Opt-In to add a specific availability schedule to the existing schedule for a discrete time. It may Opt-Out, replacing the current schedule with another for a discrete time.
Component/s: spec
Fix Version/s: (was: wd25)
Affects Version/s: wd24
> 745: Section 5.4 is VEN/VTN centric
> -----------------------------------
>
> Key: ENERGYINTEROP-443
> URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-443
> Project: OASIS Energy Interoperation TC
> Issue Type: Bug
> Components: spec
> Affects Versions: wd24
> Environment: Ed Cazalet
> Reporter: Edward Cazalet
> Assignee: Toby Considine
>
> A Party engaged in only Transactive interactions should also be able to Register Accounts. Each Partiy should have one to many Accounts. For example Walmart might have an Account for Each store or building.
> This section needs a lot of work to clearly express the use of market context and accounts for both transactive and VTN/VEN interactions. As it stands it is confusing.and needs a very careful rewrite.
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]