[OASIS Issue Tracker] (ENERGYINTEROP-715) Transaction States

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

    [ https://issues.oasis-open.org/browse/ENERGYINTEROP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=80712#comment-80712 ] 

William Cox edited comment on ENERGYINTEROP-715 at 2/7/22 10:15 PM:
--------------------------------------------------------------------

Point 24: I could not find the described text.

Point 26: The use of TransactiveStateType is indeed a vestige of an earlier approach, but the direction for some decades in software engineering is use the type of the object, rather than a value of an attribute. Alas, as a tender evolves (potentially) into a transaction, values (price, quantity) will change due to market actions. Figure 9-2 line 601 shows that EiTransaction "has an" EiTender included. (In fact, the EiTransaction is a wrapper on an evolved, rewritten Tender).

Evolving the containing set of attributes from a Tender through a Transaction seems inconsistent with current strongly-typed message structures.


was (Author: williamcox):
The use of TransactiveStateType is indeed a vestige of an earlier approach, but the direction for some decades in software engineering is use the type of the object, rather than a value of an attribute. Alas, as a tender evolves (potentially) into a transaction, values (price, quantity) will change due to market actions. Figure 9-2 line 601 shows that EiTransaction "has an" EiTender included. (In fact, the EiTransaction is a wrapper on an evolved, rewritten Tender).

Evolving the containing set of attributes from a Tender through a Transaction seems inconsistent with current strongly-typed message structures.

> Transaction States
> ------------------
>
>                 Key: ENERGYINTEROP-715
>                 URL: https://issues.oasis-open.org/browse/ENERGYINTEROP-715
>             Project: OASIS Energy Interoperation TC
>          Issue Type: Bug
>          Components: cts
>    Affects Versions: CTSPR01
>         Environment: Donald Hammerstrom https://lists.oasis-open.org/archives/energyinterop-comment/202111/msg00008/2111DJH_CTS_Review.pdf
>            Reporter: Toby Considine
>            Assignee: Toby Considine
>            Priority: Minor
>              Labels: ARCH-CONF
>
> There are 30 specific recommendations in the "Specific Recommendations" section of the submitted Hammerstrom paper. I have numbered them all for traceability as I recombine them into specific issues. The original white paper/submission can be read in the URI under "environment"
> 24. Section 8: This section points out the weakness of using transaction and Transaction differently. I liked the use of Transaction in TEMIX as a state of a transaction. All this subtle distinction is lost if capitalization is not used consistently, as is the case in this section.Â
> 26. Table 9-2: I think the fact that an EiTransaction *always* has Transactive State=transaction is a vestige of an earlier, preferable approach. Wouldnât it be much more elegant to define a single transaction behavior, in which the transaction migrates through its available states? Each of the Tender Facet, Transaction Facet (and possibly Quote Facet) should be defined as state transition behaviors, but I question why the structure of the interaction payloads should differ at all.ÂÂ
> â Tender, Transaction, Delivery, (Quote) address states of an interaction and were more clearly addressed by a TEMIX enumeration. This may be an unwise simplification, as it limits future extension of interaction attributes.Â



--
This message was sent by Atlassian Jira
(v8.3.3#803004)