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

Re: Discussion on Declarative Language for XML Processing Pipeline

From: Alessandro Vernet <avernet@orbeon.com>
Date: Wed, 8 Feb 2006 21:51:39 -0800
Message-ID: <4828ceec0602082151w5919b541qb62e54b06d49d334@mail.gmail.com>
To: public-xml-processing-model-wg@w3.org

Hi Vikas,

And where does the priority for a given step come from? Is it static?
Maybe a concrete example would help to clarify the concept of
priorities.

Alex

On 2/8/06, Vikas Deolaliker <vikas@sonoasystems.com> wrote:
> Alex,
>
> If you were to put these declarations in a config file, at run-time you
> would need to determine the sort-order i.e. what to run first if multiple
> patterns are matched on an incoming file. The sort order of steps within a
> stage is determined by priority.
>
> "Includes" help you interrupt a priority in a context by including another
> context.
>
> Vikas
>
>
> -----Original Message-----
> From: public-xml-processing-model-wg-request@w3.org
> [mailto:public-xml-processing-model-wg-request@w3.org] On Behalf Of
> Alessandro Vernet
> Sent: Wednesday, February 08, 2006 7:39 PM
> To: public-xml-processing-model-wg@w3.org
> Subject: 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/
>
>


--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/
Received on Thursday, 9 February 2006 05:51:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:47 GMT