Discussion on Declarative Language for XML Processing Pipeline

 

This is to follow up on my AI from last Thursday's concall. The AI called
for starting a discussion on declaratively specifying the pipeline.
Declarative language is mentioned in the requirements document. Here are
some thoughts on a declarative approach to defining the XML processing
pipeline declarative language. 

 

First, the definition of declarative (as used in this email) is simply to
define "What" a pipeline should look like and not "How" to go about doing
it. 

 

The granularity of the declarations requires that we put some structure on
the pipeline itself. Here are some thoughts on how we define the structure
of the pipeline. 

 

1.	The pipeline is a collection of contexts. 
2.	A context is collection of stages
3.	Each stage has one or more steps with priority associated with it. 
4.	A context can "include" other contexts
5.	The inclusion can be conditional.
6.	A stage is entered through "matching of pattern" on incoming
document
7.	There are some pre-defined patterns such as "start", "end" which
always match. 
8.	Inside a stage, all steps are executed based on given priority. 

 

 

 

Here is a simple example. 

 

[DefaultContext] //This is the context for these processing steps. 

//This context has multiple stages each defined by some pattern match. So if
the

// pattern1 matches the incoming XML, then we trigger the steps in the
stage:Pattern1

// Each step in the stage run according the priority (1,2,3) etc. If the
step generates a fault

// then corresponding fault handlers are triggered. 

// 

Match => Pattern1 (Could be XPath etc.), 1, doSomeProcessingStep1

               Pattern1 ,                                 2,
doSomeProcessingStep2

               Include AnotherContext //You can include another context in
this context

               Pattern1, 3, doSomeMoreProcessingStep3.

 

Catch => Pattern, 101, handleFaultFromProcessingStep1

Catch => Pattern, 102, handleFaultFromProcessingStep2

Catch => Pattern, 103, handleFaultFromProcessingStep3

 

//This is start of stage 2 in the context. 

Match => Pattern2, 1, doAnotherProcessingStep1

               Pattern2, 2, doAnotherProcessingStep2

 

Catch  => Pattern2, 101, handleFaultFromStep1

Catch =>  Pattern2, 102, handleFaultFromStep2

 

 

 

[AnotherContext] 

// AnotherContext is defined here and included above. Using includes, you
can insert steps which are not in priority. For example, the stages/steps
defined in this context is included after the step 2 is run in the prior
context. 

..

..

 

Hope this is enough to get the discussion started. 

 

Thanks 

Vikas