Uploaded image for project: 'OASIS Energy Interoperation TC'
  1. OASIS Energy Interoperation TC
  2. ENERGYINTEROP-584

Program definition in section 5.2.1 is not appropriate for its intended purpose and should be deleted.

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: wd29
    • Fix Version/s: wd33
    • Component/s: None
    • Labels:
      None
    • Proposal:
      Hide

      I suggest that we delete section 5.2.1 from the spec and the schemas replace it with the following. Extend the emix:itemBase with an EI specific type called levelType that has the limit attributes expressed in section 5.2.1. Since emix:itemBase is the attribute that is attached to specific signals we can use this new type to attach these attributes to a specific level signal when appropriate. I think this will achieve the same result of section 5.2.1 in cleaner and more effective fashion.

      Show
      I suggest that we delete section 5.2.1 from the spec and the schemas replace it with the following. Extend the emix:itemBase with an EI specific type called levelType that has the limit attributes expressed in section 5.2.1. Since emix:itemBase is the attribute that is attached to specific signals we can use this new type to attach these attributes to a specific level signal when appropriate. I think this will achieve the same result of section 5.2.1 in cleaner and more effective fashion.
    • Resolution:
      Hide

      Misleading Program has morphed into SimpleLevel and Level, no longer suggesting that this conveys a Program.

      Show
      Misleading Program has morphed into SimpleLevel and Level, no longer suggesting that this conveys a Program.

      Description

      Program definition in section 5.2.1 is not appropriate for its intended purpose. It is wholly inadequate and starts to tread into the realm of meta-data for programs which should not be addressed in verion 1.0 of the spec. When we do start adding meta data about programs this information should not be in the event and we should create a seperate program service with accompnaying data strcutures to express the program meta-data. Examples of meta-data we might include about a program include the following:

      • What are the program constraints, i.e. when can I expect to get signals
      • What signals can I expect to receive when I do get an event
      • For each signal what are the attributes of the signal, including type and value constraints where appropriate.
      • What type of feedback (reports) should be generated for this program

      If everyone recalls there use to be a seperate program service and one of the reasons that we deleted it was becasue we did not want to flush all this out in 1.0. In one of our TC meetings in April we decided to put this sort of program meta-data off to 1.1.

      Below I propose an alternate solution that I think will achieve the intended goal of section 5.2.1 in a much more effective fashion and not tread too far down the program meta-data rat hole.

        Attachments

          Activity

            People

            • Assignee:
              ed.koch Ed Koch (Inactive)
              Reporter:
              ed.koch Ed Koch (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: