[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: SAF call - proposed agenda for today
Alvin
& I were only two on the call today… so cancelling due to lack of
quorum. My
recommendations for 004 – Composition/Decomposition below. There are three parts
to this issue: 1.
Detecting a partial match on a syndrome This seems best
accomplished by splitting the syndrome into “sub syndromes” as
stated in the issue. For example, A syndrome detects whether symptom X & Y
occur together within 1 hour. If visibility is required into whether X and/or
Y are matched (irrespective of whether they occur together), then syndromes
should be created independently for both X & Y, as well as a syndrome for
detecting whether they occur together. My proposal: Do
nothing, as the current spec allows for this composition. 2.
Composing a syndrome from other syndromes. The spec allows for this
composability (see above example). One nice optimization would be to directly
reference syndromes from within a syndrome. The spec doesn’t explicitly
describe how this could be done, but doesn’t introduce any restrictions
either. For example, syndrome
A detects whether symptoms X & Y occur together within a 1 hour time
interval. Syndrome B detects whether symptom Z occurs. And syndrome C detects
whether symptoms X & Y occur together within a 1 hour time interval,
followed by symptom Z. A nice optimization
would be to specify syndrome C in terms of syndrome A & B. My proposal: Do
nothing, as the authoring tools could handle this optimization, while producing
the (fully exploded) xquery signature in the catalog. 3.
Decomposing an xquery into constituent elements An xquery is difficult
(and sometimes impossible) to parse into its constituent elements, ie: symptoms
and time constraints. My proposal: Do
nothing, as the authoring tools could store composable snippets independent of
the SAF catalog. The authoring tool is likely to provide a higher level
(implementation dependent) representation of a pattern, such as a google-like
search. The tool would publish to the catalog with a fully exploded XQuery signature,
while retaining its composable snippets in its private store. My recommendations for
012 – Template syndrome & protocol below. 1.
First, I provide a use case where this template idea is required: Detect symptom A & B where A.hostname=B.hostname and
A.instancename=’Blah’. Fyi – A might be an application? It would be great to allow “Blah” to be populated by
the syndrome implementer. So, the syndrome might be published into the catalog by a Cloud
provider as follows: Detect symptom A & B where A.hostname=B.hostname
and A.instancename=?. 2.
Next, how would we support this notion in the spec: We
would need some wildcard character (such as the ?) to designate to the
authoring tools that this value should be substituted. From: Vaught, Jeffrey A Today’s call, 1st November, UK time will be 2pm as
opposed to 3pm that used to be. From the week after, i.e. starting 8th
November, US clocks go back too, so call time in UK will reverse to 3pm again. Proposed agenda: -
Close
recommended issues (see notes from last week) -
Review
issue assignments from last week. §
013,017 – Stavros §
007,008 – Vivian §
005,009 – Alvin §
004,012 – Jeff §
015 – Paul -
Outreach
activities – DMTF, Oracle, OMG, etc. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]