Re: Discussion on Declarative Language for XML Processing Pipeline

Hi Vikas,

I think I agree with the concepts you're presenting here, except for
the idea of priority that I don't fully understand. Could you please
elaborate on this idea?

Alex

On 2/8/06, Vikas Deolaliker <vikas@sonoasystems.com> wrote:
>
>
>
>
>
> 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.
>
>
>
> The pipeline is a collection of contexts.
> A context is collection of stages
> Each stage has one or more steps with priority associated with it.
> A context can "include" other contexts
> The inclusion can be conditional.
> A stage is entered through "matching of pattern" on incoming document
> There are some pre-defined patterns such as "start", "end" which always
> match.
> 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
>
>


--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/

Received on Thursday, 9 February 2006 03:39:14 UTC