Re: Thinking about injection

The idea was to have some tee interface which passes the message through to the target step when no inspector is provided, otherwise it passes the message to the inspector and the target step.
This should be easy to do for implementers.

The inspector itself is a Java interface (a Scale trait?) which can be implemented by users. My idea would be to write one or two standard classes implementing e.g. writing a serialised version of the documents on the selected port to std-err, std-out or the local file system. Since the injector will receive a sequence of XML documents it is obvious one could also provide an interface to call on XProc pipeline.

I would like to think of the location specifier as a pair of an XPath match expression selecting the step (either "/p:declare-step/p:for-each[1]/p:add-attribute[@name='second-adder']" or "//*[@xml:id='me']" and the port's name.
One possible notation could then be: 

<inject path="/p:declare-step/p:for-each[1]/p:add-attribute[@name='second-adder']" port="source" injector="some.java.class.name" args="some arguments for the class instantiator"/>

------------------------------------------------
Achim Berndzen
achim.berndzen@xml-project.com

<xml-project /> Achim Berndzen
Kleine Breite 26a
38302 Wolfenbüttel, Germany

http://www.xml-project.com





> Am 21.09.2017 um 11:00 schrieb Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>:
> 
> Achim explained that since his and Norm’s new processors use message passing between steps, it should be quite easy for the processors to intercept these messages.
> 
> So whether it will be implemented by transforming existing pipelines or in the processors should be a thing that our injection spec shouldn’t be concerned about. It should only specify a declarative format in which to express your diagnostic needs in terms of location (call stack location, iteration count, port name, …), information (execution time, outputs on a port, in-scope bindings, …), and where to put this information (file URI, HTTP post, console, …).
> 
> Gerrit
> 
> 
> On 20.09.2017 16:46, Vojtech Toman wrote:
>> Some other (mostly random) ideas:
>> 5. How long did a particular step take
>> 6. What URIs the step/pipeline accessed (for read/write)
>> 7. What the in-scope variables/options bindings (or the entire in-scope environment?) are
>> 8. Dynamic errors (the source of the error etc.)
>> 9. Ability to inspect the "call stack"
>> 10. System properties (p:system-property)
>> As for the ability to inject steps, I am not convinced. It sounds appealing, but also non-trivial (and likely complicated to use). Identifying where to inject steps is one thing, but then connecting the ports together (a non-trivial task in "plain" XProc) so that it all actually works is another thing. Also, in parallel/lazy/... processors it may not be always clear when (or if at all) the injected steps get executed, so there may be various interoperability surprises.
>> I see two main points of interception: around a step invocation and/or around an input/output port. The first is probably what most people here have in mind. Useful but at the same time potentially challenging to integrate with the existing language - if you want to execute a pipeline before/after a step, what must its signature look like and how is it all connected together?
>> In contrast, intercepting an input/output port is much simpler (and probably less useful because of a narrower scope), but quite easy to integrate with the language - provided there is a way to refer to an input port, any pipeline that has one input port and one output port can be used. In a way, this could be viewed as generalized p:log. The injected pipeline can just log what appears on the port, it can transform the data on the port, etc.
>> Regards,
>> Vojtech
>> -----Original Message-----
>> From: Norman Walsh [mailto:ndw@nwalsh.com]
>> Sent: Tuesday, September 19, 2017 10:56 AM
>> To: XProc Dev
>> Subject: Thinking about injection
>> Geert Bormans <geert@gbormans.telenet.be> writes:
>>> The idea is to have an injection spec We agreed we need it, we
>>> committed to work on it soon, but we have not specified a single bit
>>> of it, so all of the following is pure speculation
>> Ok. I’m still trying to get my head around what needs to be specified.
>> Imagine I have a complicated pipeline that I think contains a bug. The goal is to have a way to enable debugging for that pipeline without changing it. And the goal of a spec would be to have an interoperable way to specify this. (Are we convinced that we need interoperability that this level?)
>> So. I might want to know:
>> 1. When a particular step runs
>> 2. What the computed values of its options are 3. What its inputs are 4. What its outputs are
>> Presumably it would be useful to enable these features with conditional expressions.
>> What more would you want?
>>                                         Be seeing you,
>>                                           norm
>> --
>> Norman Walsh
>> Lead Engineer
>> MarkLogic Corporation
>> Phone: +1 512 761 6676
>> www.marklogic.com
> 
> -- 
> Gerrit Imsieke
> Geschäftsführer / Managing Director
> le-tex publishing services GmbH
> Weissenfelser Str. 84, 04229 Leipzig, Germany
> Phone +49 341 355356 110, Fax +49 341 355356 510
> gerrit.imsieke@le-tex.de, http://www.le-tex.de
> 
> Registergericht / Commercial Register: Amtsgericht Leipzig
> Registernummer / Registration Number: HRB 24930
> 
> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
> Thomas Schmidt, Dr. Reinhard Vöckler
> ------------------------------------------------------------------------------
> Meet us at Frankfurt Book Fair
> Hall 4.2, L 72.
> 
> More at https://www.le-tex.de/en/buchmesse.html
>

Received on Thursday, 21 September 2017 10:57:15 UTC