OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saf message

[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
Sent: Monday, November 01, 2010 9:09 AM
To: saf@lists.oasis-open.org
Subject: SAF call - proposed agenda for today

 

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]