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] (ENERGYINTEROP-715) Transaction States


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

Toby Considine updated ENERGYINTEROP-715:
-----------------------------------------
    Description: 
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.Â

  was:
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.ÂÂ


> 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: https://lists.oasis-open.org/archives/energyinterop-comment/202111/msg00008/2111DJH_CTS_Review.pdfÂDonald Hammerstrom
>            Reporter: Toby Considine
>            Assignee: Toby Considine
>            Priority: Major
>
> 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)


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