I was strongly guided by a committee member
to provide a simplified guids to the
classes/Objects/Substitution groups to make understanding the
schema easier. Here is a first pass, to see if folks like it.
EMIX defines some base types that are
used to define volatile products. Because the future of
smart energy markets its not known, there is an emphasis on
extensibility and composition to allow EMIX to be suitable
for markets known and unknown, and for easy evolution. The
EMIX schema defines the framework and extensibility. Power
and Resource are effectively each an extension of this base,
defining information for power markets, and providing
examples how other schemas can claim conformance with the
base EMIX. Specifications that follow this model should be
useable in any specification that uses emic for Power.
The core extension elements are the
Product Description and the emixBase. These types are
described using the abstract types Item (itemBase), and the
Interface (emixInterface). Almost all of EMIX is built on
these four abstract types.
The Product Description is the abstract
type that is the basis for all static descriptions of EMIX
products. Product Descriptions are static in that they refer
to a particular instance in time. Most of the elements Power
and Resource schemas are creating Product Descriptions for
Power Markets.
The abstract emixBase defines how to
apply a Product Descriptions to a Schedule. That schedule
may be as simple as a single 5 minute interval on a
particular day, or as complex and repeating you can find in
your own personal calendar. Any type derived from the
emixBase can hold any Product Description. Types derived
from the EmixBase include Products, Options, TEMIX, and
Delivery (Meter Information).
These two types rely on two smaller
types that vary. All Product Descriptions contain a type
derived from the ItemBase. We borrowed Item from UBL
(Universal Business Language) where an Item is that thing on
a line of a purchase order, or of a receipt, or on a bill of
lading. The ItemBase derived types have at least a name, a
unit of measure, and a scale factor. The Power schema
defines 3 power types and three energy types from ItemBase.
All product descriptions include the
EmixInterface. The EmixInterface is where something
transfers ownership for the market. In Power, it can be a
node or meter, and aggregation of nodes or meters, a pair
of nodes, or a geographic area. Other specifications can
derive from the base type to support their own needs. Any
type derived from the Interface can be used in any of the
EmixBase derived types.
Does this help? Do folks want this in the
specification, perhaps in section 1? Any suggestions for
improvement?
“It is difficult to get a man to understand
something, when his salary depends upon his not understanding
it” -- Upton Sinclair.