Re: Thinking about port set expressions and block expressions

Alex Miłowski <alex@milowski.com> writes:
> I think we want the rules to be:
>
> 1. First you map by name.
> 2. Then by "order" (semantics TBD)

Right.

> 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
   forbidden.
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,
                                          norm

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