Ominibus Comments for Marty Burns

Resolutions inline in ALL CAPS

line # page # clause # existing language/issue proposed change
390 20 4.1.1 Party Type correct schema that uses the attribute "side"
102 11 1.6 """...elements and the names of attributes within XSD files, the names follow the lower camelCase convention...""

CORRECTED - Side used in both Schema and Spec

From NIEM NDR:
[Rule 9-6] (REF, SUB, EXT)
Within the schema, any XML Schema component other than an attribute declaration SHALL have a name that begins with an upper-case letter ('A'-'Z')." Should either adopt NIEM NDR or not. Perhaps eliminate from spec or identify the relevant portions which are followed.

LANGUAGE REMOVED. FIXED.

301 17 3 "EMIX Schemas

The table has two columns Schema and Definition. It appears that what is in the Schema column is instead a namespace and what is in the Definition column are schemas in the namespace. Suggest clarifying this." Change Schema to Namespace, Definition to EMIX Schemas in Namespace.

SECTION REWRITTEN. FIXED.

438 26 4.4 Figure 4.7 has many "anonymous" attribute names such as ref_element10 for currency. Should use appropriate names "For Example:

ref_element10 -> currency:CurrencyType, where CurrencyType is the 2417 code definition"

UML UPDATED, WILL BE PUBLISHED SHORTLY AFTER PR03. Corrected.

494 30 6.2.1 "Item Base

Verification in section 2.7 is out of scope in EMIX according to the text. However, NAESB EUI (derived from CIM) or 61968 CIM Meter model will likely be used in the verifiction process. In these models, ReadingType is the descriptor of a basic measurement. EMIX should use this model to facilitate interoperability with these standards. Additionally it supports many more types of measurements than the explicit lists you have so far." Use NAESB PAP10 ReadingType for EnergyItemType. The "Named" derived types can be restrictions on the base type by stating fixed or default values for the ReadingType attributes.

VERIFICATION IS OUT OF SCOPE. MODEL MAPS TO REQUIRED PORTIONS OF EUI MODEL; CONFORMANCE DEMONSTRATION MAY BE IN "USE OF EMIX NOTE" IN PROCESS.

577, 580 36 9.1 Base Power Contract Should be Power Product Description?

DONE

469 29 6.1 EMIX Interface allows selections by substitution group. However, this makes useful components mutually exclusive when they may go together like aggregatedPnodde and endDeviceAsset. This approach will require definitions of a substitution group for each permutation of interface attributes. Suggest more broadly defined core emixInterface with well established complementary optional components. Alternatively, make the multiplicity of emix:emixInterface maxOccur = unbounded.

SEPARATED (CLONED ISSUES) DEFERRED TO POST 1.0

591 37 9.3 "Block Power Full Requirements

Not clear where Tiers are defined except in schema snapshot. Additionally, power:charges does not seem to support Block/Tier pricing." Suggest adding description of blocks and tiers and how pricing and charges support per block/tier disaggregation. For example, a tariff with two blocks each with three tiers.

NON-NORMATIVE EXAMPLES SHOW THIS. SECTION REWRITTEN. FIXED.

305 17 3.1 "Product vs Product Description

The definition of Product (which is derived from EmixBaseType) seems to be more of a product description. Product Description which contains the scheduled component data seem more like product data. A name that more clearly delineates the definition of the product being described and the instance data about it would be helpful." Suggest Product -> ProductDefinition, ProductDescription -> Product or ProductData.

THIS WOULD REDUCE CONSENSUS. PRODUCT SECTION 2.1.1 ADDED IN WD33 AND DISCUSSION EXTENDED. FURTHER DISCUSSION ON VARYING DEFINITIONS OF "PRODUCT" IN "USE OF EMIX NOTE". WON'T FIX.