An EventConditionAction Language for XML

1
An Event-Condition-Action Language for XML

• James Bailey
• U. of Melbourne, jbailey_at_cs.mu.oz.au
• Alex Poulovassilis, Peter Wood
• Birkbeck, U. of London, ap_at_dcs.bbk.ac.uk,
  ptw_at_dcs.bbk.ac.uk

2
Introduction

• XML is becoming a standard means of storing and
  exchanging information on the Web
• XML repositories are increasingly being used in
  dynamic applications where actions need to be
  taken in a timely fashion in response to updates
  to the data
• Periodic querying is not sufficient may be too
  infrequent, or too frequent
• Thus, there is a need for reactive functionality
  on XML repositories
• event-condition-action (ECA) rules are a natural
  candidate

3
ECA Rules

• ECA rules take the form on event if condition
  do action

Event Detection
Condition Evaluation
Users/ Apps
Action Execution
4
Why not use XSLT ?

• Why not use XSLT to support reactive
  functionality on XML?
• XSLT would have to process an entire source
  document after any update to it in order to
  produce a new document
• In contrast, we envisage the need for updates of
  much finer granularity.
• Also, using ECA rules allows one to update a
  document directly whereas XSLT requires a new
  result tree to be generated by applying
  transformations to the source document.

5
ECA rules in Active Databases

• ECA rules in active (relational) databases are of
  the form
• on insert/delete/update of a table
• if SQL condition
• do SQL statement(s)
• When an insertion/deletion/update occurs, the
  DBMS provides a set of instantiations for the
  variables new and old
• These variables can be used within the condition
  and action parts

6
Some Examples

• on INSERT INTO Accounts
• if new.Amount gt 1000
• do INSERT INTO HighInterest VALUES (new.AccNo)
• on UPDATE OF Accounts.Amount
• if old.Amount gt 1000 AND new.Amount lt 1000
• do DELETE FROM HighInterest WHERE Accno
  new.AccNo
• on DELETE FROM Accounts
• if old.Amount gt 1000
• do DELETE FROM HighInterest WHERE Accno
  old.AccNo

7
ECA Rules for XML

• ECA rules are used in conventional data
  warehouses for
• incremental maintenance of materialised views
• checking integrity constraints
• performing automatic repairs when violations
  are detected
• maintaining audit trails of the data
• maintaining statistics of data warehouse
  performance and usage
• By analogy, they could be used to provide similar
  functionality on XML repositories.

8
Our ECA Language for XML

• In this paper, we present a language in which ECA
  rules on XML can be defined
• Rather than introducing yet another language for
  XML, we use fragments of the XPath and XQuery
  languages within the event, condition and action
  parts of our ECA rules
• This allows leverage of ongoing work on XPath and
  XQuery

9
Analysing XML ECA rules

• This is more complex in our XML setting than in
  relational databases because rule actions cause
  insertions or deletions of
• sub-trees within trees
• at any depth
• as opposed to
• adding/deleting/updating rows within tables,
• at one level

10
Analysing XML ECA rules

• Thus, more sophisticated analysis techniques are
  needed
• Other ECA rule languages for XML have been
  proposed but none of this work has focused on
  analysing the behaviour of the ECA rules
• The XPath and XQuery fragments we use are
  restricted to what we term simple XPath and
  simple XQuery.
• These are useful and reasonably expressive
  fragments which have the advantage of also being
  amenable to analysis.

11
Our ECA Language

• The event part of an ECA rule is of the form
• INSERT e
• or
• DELETE e
• where e is a simple XPath expression
• Simple XPath disallows the use of any axis other
  than the child, parent, self, or
  descendant-or-self axes, and the use of all
  functions other than document()

12
Our ECA Language - Events

• In a rule event part of the form
• INSERT e
• the XPath expression e evaluates to a set of
  nodes
• The rule is triggered if this set of nodes
  includes any node that has been inserted by the
  most recent update on the XML database
• The set of instantiations for the variable delta
  is the set of new nodes returned by e

13
Our ECA Language - Events

• Similarly, in a rule event part of the form
• DELETE e
• the XPath expression e evaluates to a set of
  nodes
• The rule is triggered if this set of nodes
  includes any node that has been deleted by the
  most recent update on the XML database
• The set of instantiations for the variable delta
  is the set of deleted nodes returned by e

14
Our ECA Language - Conditions

• The condition part of a rule is either TRUE, or
• one or more simple XPath expressions connected by
  and, or, not
• A rules actions are executed on each XML
  document which
• has been changed by an event of the form
  specified in the rule's event part,
• for each value of delta for which the rule's
  condition is True

15
Our ECA Language - Actions

• Each rule action is of the form
• INSERT r BELOW e
• or
• DELETE e
• e is a simple XPath expression
• r is a simple XQuery expression
• Simple XQuery disallows the use of full FLWR
  expressions, essentially permitting only the
  Return part of an expression.

16
An Example

• An XML database containing two documents s.xml
  and p.xml
• ltstoresgt
  ltproductsgt
• ltstore id"s1"gt
  ltproduct id"p1"gt
• ltlocationgt...lt/locationgt
  ltnamegt...lt/namegt
• ltmanagergt...lt/managergt
  ltpricegt...lt/pricegt
• ltproduct id"p1"/gt
  ltstore id"s1"/gt
• ltproduct id"p2"/gt
  ltstore id"s2"/gt
• ...
  
• lt/storegt
  lt/productgt
• ...
  
• lt/storesgt
  lt/productsgt

17
Example (contd)

• If one or more products are added to a store in
  s.xml, this rule appends that store to the
  children of those products in p.xml if its not
  already a child
• Rule 1
• on INSERT document('s.xml')/stores/store/produ
  ct
• if not (document('p.xml')/products/
• product_at_iddelta/_at_id/store_at_idd
  elta/../_at_id)
• do INSERT ltstore id'delta/../_at_id'/gt
• BELOW document('p.xml')/products/product_at_id
  delta/_at_id AFTER TRUE

18
Example (contd)

• In a symmetric way, if one or more stores are
  added to a product in p.xml, this rule appends
  that product to the children of those stores in
  p.xml if its not already a child
• Rule 2
• on INSERT document('p.xml')/products/product/s
  tore
• if not (document('s.xml')/stores/
• store_at_iddelta/_at_id/product_at_idd
  elta/../_at_id)
• do INSERT ltproduct id'delta/../_at_id'/gt
• BELOW document('s.xml')/stores/store_at_idde
  lta/_at_id AFTER TRUE

19
Analysing ECA Rule Behaviour

• A rule R may trigger a rule R' if execution of
  action(R) may generate an event which triggers
  event(R')
• A rule R may activate another rule R' if
  condition(R') may be changed from False to True
  after the execution of action(R)
• A rule R may activate itself if condition(R) may
  be True after the execution of action(R)

20
Analysing ECA Rule Behaviour

• Once triggering and activation relationships have
  been derived, we can construct graphs which are
  useful in analysing rule behaviour
• the triggering graph
• the activation graph
• Acyclic triggering graph gt rule execution
  terminates
• Acyclic activation graph gt rule execution
  terminates
• The triggering and activation properties are also
  useful for optimising rule execution.

21
Triggering Relationships between XML ECA rules

• For any action INSERT r BELOW e
• and any event INSERT e
• we need to know whether the event is independent
  of the action i.e. if the evaluation of e can
  never return any of the nodes inserted by the
  action

22
Triggering Relationships between XML ECA rules

• For any action INSERT r BELOW e
• and any event INSERT e
• r defines which sub-trees are inserted by the
  action
• e defines where these are inserted
• So, if some prefix of e intersects e and the
  remainder of e matches r, then the event is
  not independent of the action
• We formalise these notions in the paper, and give
  conservative tests for them. Deletions are
  treated similarly.

23
Example

• Action of Rule 2
• INSERT ltproduct id'delta/../_at_id'/gt
• BELOW document('s.xml')/stores/store_at_idde
  lta/_at_id
• Event of Rule 1
• INSERT document('s.xml')/stores/store/product
• A prefix of this event document('s.xml')/stores/
  store
• intersects the BELOW part of Rule 2s action
• The suffix, product, matches the INSERT part of
  Rule 2s action

24
Example (contd)

• So Rule 2 may trigger Rule 1
• Similarly, Rule 1 may trigger Rule 2
• Resulting triggering Graph between Rule 1 and
  Rule 2

1
2
25
Activation Relationships between XML ECA rules

• There are two cases to consider
• Activation between different rules i.e. can some
  action of R change the value of condition(R)
  from False to True?
• If so, R may activate R
• (b) Self-activation i.e. can some action of R
  leave condition(R) True?
• If so, R may activate itself.

26
Activation Relationships between XML ECA rules

• In the paper we consider in turn conditions which
  are
• simple XPath expressions
• negations of simple XPath expressions
• conjunctions of 1 and 2
• disjunctions of 3

27
Activation for simple conditions

• If R has a simple condition, R can only activate
  R' if some action of R is an insertion which is
  non-independent of R s condition
• To determine non-independence of a condition c
  from an insertion, we construct from c an
  equivalent set of conditions, C, representing all
  possible paths through c
• Then we use the same techniques as for
  triggering analysis to determine if all
  conditions in C are independent of the insertion
• If R has a negated simple condition, a similar
  analysis is used for deletion actions of R

28
Self-Activation for simple conditions

• R is self-disactivating if all its actions leave
  its condition False
• If condition(R) is a simple XPath expression c, R
  will be self-disactivating if all its actions are
  deletions which subsume c
• If condition(R) is a negated simple XPath
  expression not(c), R will be self-disactivating
  if all its actions are insertions which subsume
  c
• We formalise these notions in the paper, and give
  conservative tests for them

29
Example

• Action of Rule 1
• INSERT ltstore id'delta/../_at_id'/gt
• BELOW document('p.xml')/products/product_at_id
  delta/_at_id
• Condition of Rule 1
• not (document('p.xml')/products/product_at_iddel
  ta/_at_id/ store_at_iddelta/../_at_id)
• A prefix of the condition is identical to the
  BELOW part
• The corresponding suffix is satisfied by all the
  trees denoted by the INSERT part

30
Example (contd)

• So Rule 1 is self-disactivating
• Similarly for Rule 2
• Trivially, neither rule activates the other
• So Rules 1 and 2 always terminate (by acyclicity
  of activation graph)

31
Conclusions

• We have proposed a new language for defining ECA
  rules on XML repositories and have developed
  techniques for analysing the triggering and
  activation dependencies between such rules
• Our analysis techniques are also useful beyond
  ECA rules, since they generally determine the
  effects of updates upon queries.
• So can also be used for analysing the effects of
  other, not necessarily rule-initiated, updates
  made to an XML repository e.g.
• to determine if integrity constraints may have
  been violated, or
• whether views need to be re-calculated.

32
Future Work

• To explore further the expressiveness and
  complexity of our ECA language, including
  prototype implementation and experimentation
• To improve the precision of our analysis methods
  by incorporating extra type information available
  from DTDs or XSchema definitions
• The decidability of containment for larger
  fragments of the XPath language is an open
  problem.
• Even if a fragment of XPath is used for which
  containment is undecidable, it may be possible
  to develop useful conservative approximations

33
Appendix - ECA Rule Execution Semantics

• The input to ECA rule execution is
• an XML database a set of XML documents
• a schedule a list of updates
• Each update is a pair (action, docsAndDeltas)
• action is an action of some rule R
• docsAndDeltas is a set of pairs (doc,deltas)
• doc is the identifier of a document upon which a
  is to be applied (i.e. one of Rs candidate
  documents)
• deltas is the instantiations for delta generated
  by the event and condition part of R with respect
  to doc

34
ECA Rule Execution Semantics

• while the schedule is not empty do
• nextUpdate head (schedule)
• schedule tail (schedule)
• (changes,db) apply (nextUpdate,db)
• for i 1 to noOfRules do
• docsAndDeltas candidateDocs
  (i,changes,db)
• if docsAndDeltas is not empty then
• for j noOfActionsi downto 1 do
• schedule (actioni,j,docsAndDeltas)sc
  hedule