Re: Does XProc support event-driven processing?

Hi all,
 I'm jumping in the discussion here for the first time because I was
intrigued by this discussion on triggers/hooks in XProc. I think they could
be useful, but also in some cases, I think nature of XProc obviates the need
for these kind of triggers. I agree that triggers would be useful in a case
where you basically want to insert some kind of interceptor step on every
pipe, but also they might not be needed as much as they were in databases.

If you look at the architectures where triggers are popular, like databases
or object-oriented programming (more likely to be called hooks or
interceptors in that case), the primary concern is on describing the schema
of data or encapsulation of data. This is a very static view of an
architecture, which makes it hard when you need to introduce new dynamic
behavior like logging, profiling, etc.. There is very little support in
those architectures to represent the coarse grained data-flow of some
system, so you need some auxiliary mechanism like triggers or hooks if you
want to intercept the data-flow.

IMHO XProc on the other hand, allows programmers to describe the coarse
grained dynamic behavior of some system as the primary concern. So when it
comes time to modify or extend the dynamic behavior, it is easier to do. In
some sense, XProc has already "aspectized" the component data-flow by
forcing it to be separate from the implementation of any steps.

Eric Wohlstadter
University of British Columbia
http://www.cs.ubc.ca/~wohlstad

On Sun, Jun 14, 2009 at 3:02 PM, Mike Sokolov <sokolov@ifactory.com> wrote:

> OK after thinking for a bit, here are some possible use-cases for triggers,
> or hooks, or something like that: how would we do these in xproc today?  I
> have to apologize if this is all worked out already in the spec: I'm really
> just getting up to speed here and evaluating how we might use xproc in our
> workflows.
>
> 1) Instrumenting the pipeline
> Say you want to implement something with cross-cutting concerns like a
> debugger, profiler or logger.
> This would be something you could apply to *any* xproc pipeline without
> modifying it.
>
> 2) Intercepting outbound requests
> For example, you want to implement a URL handler that takes http requests
> and redirects them to somewhere else; say you're running unit tests, and
> want to run against a collection of test files rather than live data out in
> the wild.
> You don't want to modify your pipeline, you want to embed it in a test
> environment.
>
> that's all
>
> -Mike
>
>
> > -----Original Message-----
> > From: xproc-dev-request@w3.org
> > [mailto:xproc-dev-request@w3.org] On Behalf Of Mike Sokolov
> > Sent: Sunday, June 14, 2009 5:53 PM
> > To: 'Costello, Roger L.'; xproc-dev@w3.org
> > Subject: RE: Does XProc support event-driven processing?
> >
> >
> > I dunno, I'm thinking it sounds like taking a nice
> > well-defined processing model and throwing in extra goodies
> > without a compelling use-case.  Also, I have visions of
> > spaghetti control-flow.  Triggers are really useful in a
> > database environment since they allow you to get your code to
> > run when a system event that is out your control occurs (ie a
> > data update).  In xproc, you're already running *your code*,
> > so why do you need a trigger?
> >
> > -Mike
> >
> > > -----Original Message-----
> > > From: xproc-dev-request@w3.org
> > > [mailto:xproc-dev-request@w3.org] On Behalf Of Costello, Roger L.
> > > Sent: Sunday, June 14, 2009 5:46 PM
> > > To: xproc-dev@w3.org
> > > Subject: RE: Does XProc support event-driven processing?
> > >
> > >
> > >
> > > > could you just *always* sum the quantity * cost = total-cost as a
> > > > step near the end of your pipeline
> > >
> > > Let's look beyond the particular example and generalize:
> > >
> > >    Databases have triggers; that is, the
> > >    ability to associate rules with cells,
> > >    e.g. on update, insert or delete of cell A,
> > >    execute rule ABC.
> > >
> > >    I think it would be powerful to have an
> > >    analogous capability in XProc: if any step
> > >    in the pipeline updates, inserts, or deletes
> > >    element X, execute rule XYZ.
> > >
> > > Then, an XProc library could be used as a "rules library."
> > > The rules are triggered when certain user-defined events
> > > occur in the pipeline.
> > >
> > > What do you think?
> > >
> > > /Roger
> > >
> > > > -----Original Message-----
> > > > From: Mike Sokolov [mailto:sokolov@ifactory.com]
> > > > Sent: Sunday, June 14, 2009 4:49 PM
> > > > To: Costello, Roger L.; xproc-dev@w3.org
> > > > Subject: RE: Does XProc support event-driven processing?
> > > >
> > > > Seems naive, but could you just *always* sum the quantity * cost =
> > > > total-cost as a step near the end of your pipeline (after all
> > > > possibility of updating merch)?
> > > >
> > > > -Mike
> > > >
> > > > > -----Original Message-----
> > > > > From: xproc-dev-request@w3.org
> > [mailto:xproc-dev-request@w3.org]
> > > > > On Behalf Of Costello, Roger L.
> > > > > Sent: Sunday, June 14, 2009 4:32 PM
> > > > > To: xproc-dev@w3.org
> > > > > Subject: RE: Does XProc support event-driven processing?
> > > > >
> > > > >
> > > > >
> > > > > > Can you elaborate on what you mean by "changes" ?
> > > > >
> > > > > Suppose this XML document is flowing through an XProc pipeline:
> > > > >
> > > > > <purchases date="2009-05">
> > > > >     <merchandise>
> > > > >         <name>Sony HT-IS100 BRAVIA Home Theater Micro
> > > System</name>
> > > > >         <cost currency="USD">299.00</cost>
> > > > >         <quantity>1</quantity>
> > > > >     </merchandise>
> > > > >     <merchandise>
> > > > >         <name>ASUS Eee PC 1000HE Netbook Computer</name>
> > > > >         <cost currency="USD">379.00</cost>
> > > > >         <quantity>1</quantity>
> > > > >     </merchandise>
> > > > >     <merchandise>
> > > > >         <name>Sony ICD-PX720 Digital Voice Recorder</name>
> > > > >         <cost currency="USD">49.00</cost>
> > > > >         <quantity>1</quantity>
> > > > >     </merchandise>
> > > > >     <total-cost currency="USD">727.00</total-cost>
> > > > > </purchases>
> > > > >
> > > > > I think it would be powerful to be able to attach this
> > rule to the
> > > > > pipeline:
> > > > >
> > > > >    If any of the steps change the value of
> > > > >    a <quantity> element, fire a step
> > > > >    to update <total_cost>.
> > > > >
> > > > > Is there a way to express this?
> > > > >
> > > > > /Roger
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: mozer [mailto:xmlizer@gmail.com]
> > > > > > Sent: Sunday, June 14, 2009 2:26 PM
> > > > > > To: Costello, Roger L.
> > > > > > Cc: xproc-dev@w3.org
> > > > > > Subject: Re: Does XProc support event-driven processing?
> > > > > >
> > > > > > Can you elaborate on what you mean by "changes" ?
> > Where ? In a
> > > > > > Database ? In a file ? Which one ?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Xmlizer
> > > > > >
> > > > > > On Sun, Jun 14, 2009 at 4:49 PM, Costello, Roger
> > > > > > L.<costello@mitre.org> wrote:
> > > > > > >
> > > > > > > Hi Folks,
> > > > > > >
> > > > > > > Does XProc support event-driven processing?
> > > > > > >
> > > > > > > Here's an example to illustrate what I mean:
> > > > > > >
> > > > > > >   Hey, any time during the pipeline processing,
> > > > > > >   if the value of <Purchase_Quantity> changes,
> > > > > > >   fire a step to update <Total_Cost>.
> > > > > > >
> > > > > > > Can you think of a way to express this in XProc?
> > > > > > >
> > > > > > > /Roger
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
> >
>
>
>