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

Patterns for strings and extension needs to be applied to EI

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: wd25
    • Component/s: None
    • Labels:
      None
    • Environment:

      William Cox

    • Resolution:
      Hide

      Address all "standardized" strings in this manner, consistent with 201.

      Show
      Address all "standardized" strings in this manner, consistent with 201.

      Description

      The pattern of defined strings for a particular status attribute should be consistently described.

      See ENERGYINTEROP-201 for application to optInOut reason string.

      This is consistent with the approach agreed by the TC, and used in EMIX and WS-Calendar.

        Attachments

          Activity

          Hide
          william.cox William Cox (Inactive) added a comment -

          This is in part editorial and in part schema and model related. Please comment.

          Show
          william.cox William Cox (Inactive) added a comment - This is in part editorial and in part schema and model related. Please comment.
          Hide
          toby.considine Toby Considine (Inactive) added a comment -

          How we solved this in EMIX:

          <xs:element name="contractType" type="power:ContractTypeType"/>
          <xs:simpleType name="ContractTypeType">
          <xs:union memberTypes="power:ContractTypeEnumeratedType emix:EmixExtensionType"/>
          </xs:simpleType>
          <xs:simpleType name="ContractTypeEnumeratedType">
          <xs:restriction base="xs:string">
          <xs:enumeration value="FullRequirementsPower"/>
          <xs:enumeration value="FullRequirementsPowerWithDemandCharge"/>
          <xs:enumeration value="FullRequirementsPowerWithMaximumAndMinimum"/>
          <xs:enumeration value="HourlyDayAheadEx-AnteRealTimePrice"/>
          <xs:enumeration value="TimeOfUsePricing"/>
          <xs:enumeration value="TransportService"/>
          <xs:enumeration value="CongestionRevenueRights"/>
          </xs:restriction>
          </xs:simpleType>

          <xs:simpleType name="EmixExtensionType">
          <xs:annotation>
          <xs:documentation>Pattern used for extending string enumeration, where allowed</xs:documentation>
          </xs:annotation>
          <xs:restriction base="xs:string">
          <xs:pattern value="x-\S.*"/>
          </xs:restriction>
          </xs:simpleType>

          This defines a general extension pattern (x-*), and a known list, and defines the valid enumerations as the union of the two. It also restricts the extensions to strings only, and not a rational for tunnelling.

          Show
          toby.considine Toby Considine (Inactive) added a comment - How we solved this in EMIX: <xs:element name="contractType" type="power:ContractTypeType"/> <xs:simpleType name="ContractTypeType"> <xs:union memberTypes="power:ContractTypeEnumeratedType emix:EmixExtensionType"/> </xs:simpleType> <xs:simpleType name="ContractTypeEnumeratedType"> <xs:restriction base="xs:string"> <xs:enumeration value="FullRequirementsPower"/> <xs:enumeration value="FullRequirementsPowerWithDemandCharge"/> <xs:enumeration value="FullRequirementsPowerWithMaximumAndMinimum"/> <xs:enumeration value="HourlyDayAheadEx-AnteRealTimePrice"/> <xs:enumeration value="TimeOfUsePricing"/> <xs:enumeration value="TransportService"/> <xs:enumeration value="CongestionRevenueRights"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="EmixExtensionType"> <xs:annotation> <xs:documentation>Pattern used for extending string enumeration, where allowed</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="x-\S.*"/> </xs:restriction> </xs:simpleType> This defines a general extension pattern (x-*), and a known list, and defines the valid enumerations as the union of the two. It also restricts the extensions to strings only, and not a rational for tunnelling.
          Hide
          william.cox William Cox (Inactive) added a comment -

          Following NIEM Naming and Design rules for extensibility. Make reference to NIEM document. Include section on how this works (viz. EMIX section with similar goals).

          Show
          william.cox William Cox (Inactive) added a comment - Following NIEM Naming and Design rules for extensibility. Make reference to NIEM document. Include section on how this works (viz. EMIX section with similar goals).
          Hide
          toby.considine Toby Considine (Inactive) added a comment -

          As voted in meeting

          Show
          toby.considine Toby Considine (Inactive) added a comment - As voted in meeting

            People

            • Assignee:
              toby.considine Toby Considine (Inactive)
              Reporter:
              william.cox William Cox (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: