W3C home > Mailing lists > Public > xproc-dev@w3.org > December 2017

RE: implicit option connections

From: Erik Siegel <mailing@xatapult.nl>
Date: Wed, 13 Dec 2017 12:28:22 +0100
To: "'Kraetke, Martin, le-tex'" <martin.kraetke@le-tex.de>, <xproc-dev@w3.org>
Message-ID: <002701d37405$7c34cd10$749e6730$@xatapult.nl>
Hi Martin,

Ok, lets discuss this in Prague. Maybe we should have some attribute then to turn it on or off. Off by default to prevent unwanted newbie side effects?  Like the @expand-text?

Erik

> -----Oorspronkelijk bericht-----
> Van: Kraetke, Martin, le-tex [mailto:martin.kraetke@le-tex.de]
> Verzonden: woensdag 13 december 2017 11:56
> Aan: Erik Siegel <mailing@xatapult.nl>; xproc-dev@w3.org
> Onderwerp: Re: implicit option connections
> 
> Hi Erik,
> 
> sorry, for this late reply, but the past weeks have been extremely busy.
> And thanks for your highly appreciated feedback!
> 
> I think the <p:with-option-map> would be a very helpful when you want to
> turn a map into a set of options from the view of a discrete step. I would
> suggest that we should put this on the agenda in Prague.
> 
> But I think my use case is different. I would like that the options in scope are
> automatically passed as options to a discrete step rather than converting
> them previously to a map. I just don't like to waste lines of code with
> declaring obvious things.
> 
> Furthermore, this would encourage people to name options consistently
> across different pipelines. As the options are still declared on the top of the
> pipeline, it shouldn't be too hard to figure out, which options are in scope.
> 
> I admit there is a risk that for example someone uses an option named
> "href" in a pipeline with a p:store where the one forget to declare the href
> explicitely in case the options should have different values. But I think it's
> easy to debug an option. You'll just need a p:message and that's it.
> 
> I'll create an issue for this feature at https://github.com/xproc/3.0-
> specification and we can discuss this in more detail in Prague.
> 
> best, Martin
> 
> 
> Am 01.12.2017 um 09:39 schrieb Erik Siegel:
> > Hi all,
> >
> > What about this to satisfy your use case:
> >
> > Maybe we could add a <p:with-option-map> element that accepts a
> map(xs:QName, item()) and turns the entries in the map into options?
> >
> > Erik
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Erik Siegel [mailto:mailing@xatapult.nl]
> >> Verzonden: donderdag 30 november 2017 16:09
> >> Aan: 'Martin Kraetke, le-tex' <martin.kraetke@le-tex.de>;
> >> xproc-dev@w3.org
> >> Onderwerp: RE: implicit option connections
> >>
> >> Hi Martin,
> >>
> >> Nice syntactic sugar and might save you quite a lot of keystrokes.
> >> But my first reaction is:
> >> * It goes against the normal programming paradigm of passing
> >> parameters to procedures/functions/methods and therefore makes the
> >> language harder to learn. Auto-passing options might also give
> >> surprising results if you're not aware of an option for some step
> >> * There is a mechanism for passing in a whole bunch of parameters in
> >> one go in XProc 3: maps.
> >>
> >> So given the excellent alternative I would at this moment advise
> >> against it to prevent making the language even more away of the
> >> mainstream than it already is.
> >>
> >> Erik Siegel
> >>
> >>> -----Oorspronkelijk bericht-----
> >>> Van: Martin Kraetke, le-tex [mailto:martin.kraetke@le-tex.de]
> >>> Verzonden: donderdag 30 november 2017 11:21
> >>> Aan: xproc-dev@w3.org
> >>> Onderwerp: implicit option connections
> >>>
> >>> Hi,
> >>>
> >>> In XProc 1.0 primary input and output ports are implicitly
> >>> connected, if no explicit connection is declared. This is very
> >>> convenient, because you can write more compact code.
> >>>
> >>> I wonder if we can have the same feature for options in XProc 3.0?
> >>> In our pipelines, we use frequently the same set of options. With
> >>> 1.0 we are forced to declare them explicitely for each step. IMHO,
> >>> this results in many redundant code lines and makes the pipeline
> >>> harder to
> >> read.
> >>> Therefore, I would propose to specifiy implicit option connections for
> 3.0:
> >>>
> >>> If one or more options are in the scope of a step which expects
> >>> these options, they should be automatically passed to the step. In
> >>> this case, it should not be required to declare them explicitely
> >>> with <p:with-option> unless you want to.
> >>>
> >>> The pipeline below provides a brief demonstration of implicitely
> >>> connected options.
> >>>
> >>> <?xml version="1.0" encoding="UTF-8"?> <p:declare-step
> >>> xmlns:p="http://www.w3.org/ns/xproc"
> >>>    xmlns:c="http://www.w3.org/ns/xproc-step"
> >>>    version="3.0">
> >>>
> >>>    <p:input port="source">
> >>>      <p:inline>
> >>>        <doc>Hello world!</doc>
> >>>      </p:inline>
> >>>    </p:input>
> >>>    <p:output port="result"/>
> >>>
> >>>    <p:option name="attribute-name" select="'foo'"/>
> >>>    <p:option name="attribute-value" select="'bar'"/>
> >>>
> >>>    <p:add-attribute match="/doc"/>
> >>>
> >>> </p:declare-step>
> >>>
> >>> In case, you want to avoid an implicit connection, the easiest way
> >>> to do so is to declare the option explitely. If you do not want that
> >>> the option is declared at all, I would suggest to add an empty
> >>> <p:with-option/> for that step.
> >>>
> >>> Please let me know, what do you think about implicit option
> connections?
> >>>
> >>> Kind regards,
> >>>
> >>> Martin
> >>>
> >>> --
> >>> Martin Kraetke
> >>> Lead Content Engineer
> >>> le-tex publishing services GmbH
> >>>
> >>> Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356
> >>> 143, Fax +49 341 355356 543 martin.kraetke@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
> >>
> >>
> >
> >
Received on Wednesday, 13 December 2017 11:29:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:17:35 UTC