Re: Thinking about injection

Vojtech Toman <vtoman@opentext.com> writes:
> As for the ability to inject steps, I am not convinced. It sounds
> appealing, but also non-trivial (and likely complicated to use).

Yes, I don’t think it makes sense to specify that arbitrary steps can
be injected. I’m thinking that what you can inject is really some sort
of “observation” step (so the implementor doesn’t have to implement it
literally with injection). Let’s imagine something XML-flavored:

  <watch port="[steplocator].outputport" when="xpathexpr"
         report="xpathexpr" href="somefile"/>

I’m not sure what [steplocator] is. Conceptually, it’s some way to
identify a particular step. I’m a little reluctant to do that with an
XPath expression over the pipeline source XML. Some possibilities:

1. Step ID (with @xml:id). Fine, but what if there isn’t one.
2. Step name. Fine, but they only have to be unique within a scope.
3. The tumbler-style !1.2.2.1 name that we use as defaults.

Anyway. Watch the “outputport” of some step. Each document that passes
through becomes the context node for the “when” expression. The when
expression can refer to variable bindings that are available at the
point of observation. The observed document is reported if the
effective boolean value of the when expression is true. The default
expression is “true()”.

What’s reported is the result of evaluating the “report” expression
which defaults to “.”

The output goes to the href document (or directory), which defaults to
the console.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com