[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (EMIX-400) Ominibus Comments forMarty Burns
[ http://tools.oasis-open.org/issues/browse/EMIX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
William Cox updated EMIX-400:
-----------------------------
Description:
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.
was:
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...""
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.
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.
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"
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.
577, 580 36 9.1 Base Power Contract Should be Power Product Description?
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.
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.
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.
Resolution:
Per notes in ALL CAPS in Description. Separated issues:
l469 Deferred Post 1.0 (new issue)
Issues with reference to Using Emix Note will be set up as new issues against the Note component in the near future. (l494, l305) (new issues from clone)
> Ominibus Comments for Marty Burns
> ---------------------------------
>
> Key: EMIX-400
> URL: http://tools.oasis-open.org/issues/browse/EMIX-400
> Project: OASIS Energy Market Information Exchange (eMIX) TC
> Issue Type: Improvement
> Affects Versions: csprd02 Public Review Draft
> Environment: Marty Burns
> Reporter: Toby Considine
> Assignee: William Cox
> Fix For: wd29
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]