OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (ENERGYINTEROP-600) Create RequestPendingEvents/ReplyPendingEvent operations in EiEvent Service; add definition of "Pending"


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

William Cox updated ENERGYINTEROP-600:
--------------------------------------

        Summary: Create RequestPendingEvents/ReplyPendingEvent operations in EiEvent Service; add definition of "Pending"  (was: Create EiPushPendingEvents operation in EiEvent Service; add definition of "Pending")
    Description: 
See also ENERGYINTEROP-595 and ENERGYINTEROP-597. This partially addresses ENERGYINTEROP-481 (previously closed).

The following use case was described:

A VEN pushes a list of the event IDs it's working on to its VTN.  This can be symmetric, allowing for push of relevant and/or restricted set of Event IDs.

The events are those that are "pending".

This relates to text using pending at table/text lines 1011, 1164, 1344, and 1869.

Add a definition of Pending:

A PENDING event is one where the present time is within the closed interval from and including the notification time, and to and including the end time.

(in other words, the present is in the [notification-time, end-of-event-time] closed interval)

I propose that the service be named not Status (because it's not clearly event status) but"EiPushPendingEvents".

Source is either Ven or VTN. May be limited to those that the sender wants to communicate. No response, as it's a hint and oneway.

Attributes of the request:

List of EventIDs, possibly empty
VEN ID [0..1]
VTN ID [0..1]
emix:MarketContextType [0..1] - if absent, relationships in any market context that the destination and source of the request are engaged in.


  was:
See also ENERGYINTEROP-595 and ENERGYINTEROP-597

The following use case was described:

A VEN pushes a list of the event IDs it's working on to its VTN.  This can be symmetric, allowing for push of relevant and/or restricted set of Event IDs.

The events are those that are "pending".

This relates to text using pending at table/text lines 1011, 1164, 1344, and 1869.

Add a definition of Pending:

A PENDING event is one where the present time is within the closed interval from and including the notification time, and to and including the end time.

(in other words, the present is in the [notification-time, end-of-event-time] closed interval)

I propose that the service be named not Status (because it's not clearly event status) but"EiPushPendingEvents".

Source is either Ven or VTN. May be limited to those that the sender wants to communicate. No response, as it's a hint and oneway.

Attributes of the request:

List of EventIDs, possibly empty
VEN ID [0..1]
VTN ID [0..1]
emix:MarketContextType [0..1] - if absent, relationships in any market context that the destination and source of the request are engaged in.



Following up on GGray's comment, this differs from EiRequestEvent in three important ways:

(1) It returns IDs only (could do this with a flag that says "just return IDs")

(2) It returns only PENDING events, those that overlap the present moment

(3) It's a push operation (In that sense, RequestEvents is a pull - you ask for the events you know about and you get the events back, which includes the ID) combined with (1) - only IDs.

I've changed this to EiRequestPendingEvents/EiReplyPendingEvents.  

Note that pushing will happen on an application defined schedule.

> Create RequestPendingEvents/ReplyPendingEvent operations in EiEvent Service; add definition of "Pending"
> --------------------------------------------------------------------------------------------------------
>
>                 Key: ENERGYINTEROP-600
>                 URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-600
>             Project: OASIS Energy Interoperation TC
>          Issue Type: Improvement
>          Components: model, schema, service, spec
>    Affects Versions: wd32
>         Environment: William Cox and Ed Koch
>            Reporter: William Cox
>            Assignee: Gerald Gray
>             Fix For: wd33
>
>
> See also ENERGYINTEROP-595 and ENERGYINTEROP-597. This partially addresses ENERGYINTEROP-481 (previously closed).
> The following use case was described:
> A VEN pushes a list of the event IDs it's working on to its VTN.  This can be symmetric, allowing for push of relevant and/or restricted set of Event IDs.
> The events are those that are "pending".
> This relates to text using pending at table/text lines 1011, 1164, 1344, and 1869.
> Add a definition of Pending:
> A PENDING event is one where the present time is within the closed interval from and including the notification time, and to and including the end time.
> (in other words, the present is in the [notification-time, end-of-event-time] closed interval)
> I propose that the service be named not Status (because it's not clearly event status) but"EiPushPendingEvents".
> Source is either Ven or VTN. May be limited to those that the sender wants to communicate. No response, as it's a hint and oneway.
> Attributes of the request:
> List of EventIDs, possibly empty
> VEN ID [0..1]
> VTN ID [0..1]
> emix:MarketContextType [0..1] - if absent, relationships in any market context that the destination and source of the request are engaged in.

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