W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2006

Discussion on Declarative Language for XML Processing Pipeline

From: Vikas Deolaliker <vikas@sonoasystems.com>
Date: Wed, 8 Feb 2006 10:40:08 -0800
To: <public-xml-processing-model-wg@w3.org>
Cc: <vikas@sonoasystems.com>
Message-ID: <000a01c62cdf$16570a50$fb81140a@calvin>

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


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

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

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

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




Hope this is enough to get the discussion started. 




Received on Wednesday, 8 February 2006 18:40:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:39 UTC