[OASIS Issue Tracker] Updated: (SAF-6) SignatureComposition/Decomposition and Partial matches

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/SAF-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeffrey Vaught updated SAF-6:
-----------------------------

    Proposal: 
Jeff - Decomposition of single XQuery signature could prove difficult for Catalog Editors.  This might be implementation detail, a Catalog editor may render entirely different pattern representation (google search pattern) which is stored independently with reference to the normative Xquery.

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.


  was:Jeff - Decomposition of single XQuery signature could prove difficult for Catalog Editors.  This might be implementation detail, a Catalog editor may render entirely different pattern representation (google search pattern) which is stored independently with reference to the normative Xquery.


> Signature Composition/Decomposition and Partial matches
> -------------------------------------------------------
>
>                 Key: SAF-6
>                 URL: http://tools.oasis-open.org/issues/browse/SAF-6
>             Project: OASIS Symptoms Automation Framework (SAF) TC
>          Issue Type: Task
>            Reporter: Jeffrey Vaught
>            Assignee: Jeffrey Vaught
>            Priority: Critical
>
> As termed in the Spec (Future Development): While the Signature in a Syndrome is specified as a single XPath expression, it is acknowledged by the authors that processing of this expression may be performed incrementally to reflect the dynamic nature of Symptom creation. It may be necessary to decompose, explicitly in the specification, this XPath expression into a conjunction of multiple, simpler expressions.  
> .
> Original discussion:
> Consider Syndrome #1 that has a signature of A & B & C within 10 minutes.  Symptoms A & B are generated.  Should the diagnostician detect the partial match and "recommend" Syndrome #1 has a possible diagnosis?   If the answer is "yes", we may need to add additional elements to our signature definition to accommodate such a scenario.  IMHO (Jeff and seconded by Dave) - better to factor this out to different Syndromes, ie: Syndrome #1 is A&B&C, but Syndrome #2 is A&B.  Now, if Symptoms A&B are generated, then Syndrome #2 is diagnosed and its associated prescription "could" tease Symptom C into existence - ultimately causing Syndrome #1 to be diagnosed.
> Additional discussion from 11/5/2009: 
> Might need sets/unions of xpath2 expressions in order to be fully decomposable (such as by authoring tools).
> For example, consider case where A is followed by B is followed by C within a 5 minute time window.  Below might be XQuery, not XPath, but for sake of argument should be Ok.
> (: ABDI time sequence query :)
> let $a := //SYMPTOM[CONTENT/MSG='INFO:bobcat_command, command'] intersect //SYMPTOM[CONTENT/EXTRA='APPSRVMN']
> let $b := //SYMPTOM[CONTENT/MSG='INFO:bobcat_command, waiting command completed'] intersect //SYMPTOM[CONTENT/EXTRA='APPSRVMN']
> let $c := //SYMPTOM[CONTENT/MSG='INFO:bobcat_command, command ended with exit code: 1'] intersect //SYMPTOM[CONTENT/EXTRA='APPSRVMN']
> return 	if (boolean($a) and boolean($b) and boolean($c) and
> 	($a/TIME < $b/TIME) and ($b/TIME < $c/TIME) and
> 	($c/TIME - $a/TIME < 300))
> 	then concat($a,$b,$c) 	else ()
> While it is possible to compose such an expression, it may not be possible to decompose that expression into its constituents (A, B, C, causal relation between them, and 5 minute constraint).

-- 
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