Re: Thinking about port set expressions and block expressions

Alex Miłowski <> writes:
> 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").

I think that’s consistent with what I said. It’s certainly consistent
with what I *meant*.

> [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 I follow. I think we both agree that “style.xsl” appears
on the stylesheet input port of the xslt step.

The possibilities for the “source” port that I see are:

1. Error, you have to look “backwards” (in some sense) and that’s
2. “doc.xml” appears because it’s the first “unused” input.
3. “style.xsl” appears because it’s the first input.

I think you’re advocating for 3, which I confess hadn’t occurred to me.
I think that’s a little … odd. It seems to me that if you’ve selected
inputs by name, those shouldn’t also be selected by ordinal position.

> 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).

Ah, yes, that’s a good point. So @secondary or port("secondary").
I think that’s right.

                                        Be seeing you,

Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676

Received on Friday, 15 April 2016 17:06:53 UTC