Re: Thinking about port set expressions and block expressions

I think we want the rules to be:

1. First you map by name.
2. Then by "order" (semantics TBD)

That way we can make this work":

 xslt() -> store(href="output.xml")

After the chain operator, the current readable ports are:

[result: (...), secondary: (...)]

and the store operator has a single input port named "source".  There
is no source output port and so it uses the first port (i.e.,
"result").

[stylesheet="style.xsl", "doc.xml"] -> xslt()

The current readable ports are as specified so by these rules, XSLT
transforms the stylesheet and "doc.xml" is ignored - no error.

I'm not sure we want to automatically surface readable port names as
variables.  I think there would be a lot of room for collision with
user-defined variables.  If you want to refer to $secondary, then we
need a specialize syntax (e.g., Murray's suggestion of @secondary).


On Fri, Apr 15, 2016 at 8:29 AM, Norman Walsh <ndw@nwalsh.com> wrote:
> It's been a long time since we talked about the signatures for steps.
> Suppose we used square brackets there too:
>
>   declare step xslt($mode as xs:QName, $params as map())
>         [$source, $stylesheet; $result, $secondary]
>   {
>     ...
>   }
>
>   Aside: we seem to have some inconsistency about whether port names
>   have $-prefixes or not.
>
> I'm not sure it's syntactically the best thing ever, but ...
>
> Now we can say that a port set expression provides a mapping of
> readable ports for the step that follows:
>
>   [source="doc.xml", "style.xsl"] -> xslt()
>
> (I kind of like the arrow for readability but I think Henry's right,
> it has no purpose except readability.)
>
> I imagine that the semantics of that mapping are something like this:
>
> Given a set of readable ports and a set of input ports, you match up
> the named ones first then you match up the remaining ones in order.
>
> So each of the following binds source and stylesheet for the following
> xslt() step just as you'd expect:
>
>   [source="doc.xml", "style.xsl"] -> xslt()
>   [source="doc.xml", stylesheet="style.xsl"] -> xslt()
>   [stylesheet="style.xsl", source="doc.xml"] -> xslt()
>   ["doc.xml", "style.xsl"] -> xslt()
>
> For a case where the named and ordinal ones are "out of order":
>
>   [stylesheet="style.xsl", "doc.xml"] -> xslt()
>
> I think there are two alternatives. We can say that this binding works
> by matching up the stylesheet port by name and the source port from
> the remaining possibilities ordinally or we can make it an error
> because you have to "go backward" to make it work. (I can't think of a
> concise way to express the error condition, but I think I can see it
> pretty clearly.)
>
> I'm naturally inclined to prefer to make it an error, but I'm not sure
> that's the right thing because I don’t think we want to make extra
> ports an error. I think both:
>
>   [source="doc.xml", "style.xsl", "alt.xml"] -> xslt()
>   [source="doc.xml", alt="alt.xml", stylesheet="style.xsl"] -> xslt()
>
> bind source to "doc.xml" and stylesheet to "style.xsl" in the XSLT
> step. The extra binding is just ignored; there's no way for the XSLT
> step to read it.
>
> Another interesting case is when the names don't match up at all:
>
>   [result="doc.xml", "style.xsl"]
>
> I think the right answer here is to say that names which don't match
> are ignored. So the preceding port set expression is exactly
> equivalent to ["doc.xml", "style.xsl"] for a following xslt() step;
> if the following step has a 'result' input port then it gets doc.xml.
>
> Absent ports are just treated as empty:
>
>   [stylesheet="style.xsl"] -> xslt()
>
> binds the stylesheet to "style.xsl" and leaves the source input empty.
> I suppose you could also do that this way: [(), "style.xsl"] though
> I'm not sure we've worked out what kinds of expressions can go in a
> port set expression.
>
> The result of a step is, I think, a port set expression that binds
> the output ports to the results. So the xslt() step produces a binding
> that's equivalent to this:
>
>    [result="result.xml", secondary="secondary.xml"]
>
> By the rule that says that port names that don't match are simply
> ignored, we can still say that:
>
>    xslt() -> store(href="output.xml")
>
> would store "result.xml" into "output.xml" but would do nothing with
> the secondary output. If you want to remap things, you have to put in
> a port set expression.
>
>    xslt() -> [source=port("secondary")] -> store("secondary.xml")
>
> And it occurs to me that a port set expression doesn't even need
> the port() function if we say that it can refer to the names of
> readable ports directly:
>
>    xslt() -> [$secondary] -> store("secondary.xml")
>
> All of the preceding is back-formation from my idea for block
> expressions, which is to make them anonymous steps.
>
> xproc version = "2.0";
> inputs  $source as document-node();
> outputs $result as document-node();
>
> [$source] → λ()[$in;$out] { if (xs:decimal($in/*/@version) < 2.0)
>                             then [$in,"v1schema.xsd"] → validate-with-xml-schema() ≫ $out
>                             else [$in,"v2schema.xsd"] → validate-with-xml-schema() ≫ $out }
>           → [$out,"stylesheet.xsl"] → xslt()
> ≫ $result
>
> It's a little bit of extra syntax, but I think JavaScript and futures
> have made anonymous functions commonplace.
>
> They also afford some interesting flexibility, consider:
>
> xproc version = "2.0";
> inputs  $source as document-node();
> outputs $result as document-node();
> options $minver as xs:decimal := 2.0,
>         $v1schema := "v1schema.xsd",
>         $v2schema := "v2schema.xsd";
>
> [$source] → λ($vertest as xs:decimal := $minver,
>               $v1 as xs:string := $v1schema,
>               $v2 as xs:string := $v2schema)
>             [$in;$out]
>             { if (xs:decimal($in/*/@version) < $vertest)
>                             then [$in,$v1] → validate-with-xml-schema() ≫ $out
>                             else [$in,$v2] → validate-with-xml-schema() ≫ $out }
>           → [$out,"stylesheet.xsl"] → xslt()
> ≫ $result
>
> I'm not sure how useful that is, really, but ...
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com



-- 
--Alex Miłowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Friday, 15 April 2016 16:25:57 UTC