Download WS-Calendar_Rules_and_Conformance D2 20110113

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
2
Conformance and Rules for WSCalendar and Referencing Specifications
3
William Cox Draft 2 of 13 January 2011
4
1. Introduction
5
6
7
This is a discussion paper describing proposed approaches to conformance,
inheritance, and use of WS-Calendar. This document gives examples for how EMIX
would define conformance to WS-Calendar for EMIX artifacts.
8
Not all attributes are correctly named in this draft.
1
9
10
There are five kinds of conformance that must be addressed for WS-Calendar and
specifications that reference WS-Calendar.
11
12
1. Conformance to the inheritance rules in WS-Calendar, including the
direction of inheritance
13
2. Specific attributes for each type that MUST or MUST NOT be inherited.
14
3. Conformance rules that Referencing Specifications MUST follow
15
16
4. Description of Covarying attributes with respect to the Reference
Specification
17
5. Semantic Conformance for the information within the artifacts exchanged.
18
We address each of these in the following sections.
19
2. Rules in WS-Calendar
20
In this section we define rules that define inheritance including direction.
21
22
23
I1: Proximity Rule Within a given sequence the Parent Gluon closest (with respect
to number of links to the Designated Interval) SHALL bequeath attributes to the
Designated Interval.
24
25
26
I2: Direction Rule Intervals MAY inherit attributes from the nearest gluon subject
to the Proximity Rule and Override Rule, provided those attributes are defined as
Inheritable.
27
28
29
I3: Override Rule If and only if there is no value for a given attribute of a Gluon or
Interval, that Gluon or Interval SHALL inherit the value for that attribute from its
nearest Ancestor in conformance to the Proximity Rule
30
31
32
I4: Comparison Rule Two Sequences are equivalent if a comparison of the
respective Intervals succeeds as if each Sequence were fully Bound and redundant
Gluons are removed.
Cox
1
Conformance + Rules Draft 2
33
34
35
36
I5: Designated Interval Inheritance [To facilitate composition of Sequences] the
Designated Interval in the ultimate Ancestor of a Gluon is the Designated Interval of
the composed Sequence.1 Special conformance rules for Designated Intervals apply
only to the Interval linked from the Designator Gluon.
37
3. Specific Attribute Inheritance in WS-Calendar
38
39
In WS-Calendar the following attributes MUST be inherited in conformance to the
Rules (same for Gluons and Intervals):
40

dtStart
41

dtEnd
42

duration
43

DesignatedInterval (Gluon, special upward inheritance rule)
44

…
45
In WS-Calendar the following attributes MUST NOT be inherited
46

UID (Gluons and Intervals)
47

Temporal Relationships (Intervals)
48

…
49
We are assuming here that sequences can be composed to form new sequences.
This needs detailed discussion as the rules for Designated Intervals cannot easily be
applied to a sequence of sequences.
1
Cox
2
Conformance + Rules Draft 2
50
4. Conformance in WS-Calendar
51
In this section we propose conformance clauses for WS-Calendar.
52
53
Some of these are modeled and described as constraints in the UML models that
have been produced separately.
54
1.
Gluons and Intervals SHALL have values assigned for dtStart and duration
55
2.
Gluons and Intervals SHALL have no value assigned for dtEnd2
56
57
3.
Within a Sequence at most the Designated Interval may have dtStart and
duration with a value specified or inherited.3
58
59
4.
Any specification claiming conformance to WS-Calendar MUST satisfy all
of the following conditions:
60
a. Follow the same style of inheritance (per the Rules)
61
62
b. Specify attribute inheritability in the specification claiming
conformance
63
64
65
c. Specify whether certain sets of elements must be inherited as a group
or specify that all elements can be inherited or not on an individual
basis.
66
While VTODO objects allow for all three of dtStart, dtEnd, and duration, the
scheduling use for automation is simpler if only dtStart and duration are used. This
should be considered a canonical representation for WS-Calendar.
3 Note that composition of Sequences to create other Sequences raises issues both of
inheritance direction and the meaning of subsequences. We suggest an approach of
ignoring Designated Intervals with respect to the composed sequence as simpler
than having the new subsequences change form and not be reusable.
2
Cox
3
Conformance + Rules Draft 2
67
5. Sketch Application to EMIX
68
69
In this section we propose a set of rules and conformance statements that would
allow EMIX to claim conformance to WS-Calendar.
70
Inheritance Rules for EMIX [sketch]
71
Attribute names and grouping is not precise in this draft.
72
73
1.
The use of Sequences in EMIX SHALL follow the WS-Calendar rules for
inheritance
74
75
2.
The following attributes MUST be inherited in conformance to the WSCalendar Rules:
76
77
a. All WS-Calendar attributes used, including dtStart , duration, and
Designated Interval links
78
79
b. The following EMIX attributes SHALL be inheritable in conformance
to the Rules:
80
i. Price
81
ii. Product Definition / emixTerms
82
iii. Quantifiers for Products
83
iv. Currency
84
85
v. [complete for all potentially inheritable attributes tied to a
Sequence]
86
c. The following EMIX attributes MUST NOT be inherited:
87
i. Voltage
88
ii. Frequency
89
iii. interfacePricingPoint4
90
iv. transactiveState
91
v. uid
92
vi. createdDateTime
93
94
vii. [complete for all potentially inheritable attributes tied to a
Sequence]
95
96
d. For Power.xsd the following EMIX attributes SHALL be inherited in
conformance to the Rules: [offerPower is similar]
97
i. mRID/uid
98
ii. Notification Interval
99
iii. Transaction Node
4
Location, choice of pNode, anode, serviceLocation, serviceArea
Cox
4
Conformance + Rules Draft 2
100
iv. MinOperatingPower
101
v. MaxOperatingPower
102
e. For Power.xsd the following EMIX attributes MUST NOT be inherited:
103
i. powerAttributes including hertz, voltage, ac/dc
104
105
ii. [complete for all potentially inheritable attributes tied to a
Sequence]
106
f. For Tenders the following attributes MUST NOT be inherited:
107
i. Uid
108
ii. createdDateTime
109
iii. Price
110
111
iv. [complete for all potentially inheritable attributes tied to a
Tender]
112
Conformance for EMIX [sketch]
113
Attribute names and group is not precise in this draft.
114
115
1.
Syntactic: all EMIX artifacts MUST be well-formed and valid XML.
116
117
2.
Semantic conformance is partially defined to include the Transactive
State of the EMIX artifact.
118
119
120
3.
Further semantic conformance, out of scope for EMIX, may be defined
within the marketContext (e.g., by market rules related to the
marketContext)
121
122
4.
A product type that is not known to the interpreting software MUST be
ignored.
123
124
5.
Partially Bound artifacts SHALL be processed subject to semantic
constraints
125
6.
Market rules within the referenced marketContext MAY be applied
126
127
128
The following table suggests the relationship between transactive state and time
and binding of artifacts:
Transactive State
Time
Binding
Tender
—
>= Partial Bound
Contract
Partially Anchored
>= Partially Bound
Performance
Fully Anchored
Fully Bound
129
Cox
5
Conformance + Rules Draft 2