Re: flow example from Henry's work

I wouldn't say that it was decided in as much as recognized as
something we want to avoid.  The use of variables has to be consistent
within a lexical context.  In this particular situation, the previous
example used the same variable name for two different things.

I think the inner step chain needs to be:

$source → replace($match) {
  $source → projection(template("/*/@{($attr)}")) ≫ $ca
  { if($lex($ca))
         then xquery(template("attribute {($attr)} {( $lex($ca) )}")
         else $ca } ≫ $result
} ≫ $result

If we changed the default names for replace it might be easier to understand:

$source → replace($match) {
  $matched → projection(template("/*/@{($attr)}")) ≫ $ca
  { if($lex($ca))
         then xquery(template("attribute {($attr)} {( $lex($ca) )}")
         else $ca } ≫ $replacement
} ≫ $result

Also, the step chain in the then has no input port.  I think the
expanded form of that is:

   template("attribute {($attr)} {( $lex($ca) )}") → xquery()

and I'm not sure of the semantics of the "template" step as you've
imagined it.  I presume that $attr, $lex, and $ca all need to in-scope
within some expression language.  How are those to be bound or are
they picked up from the current lexical scope?



On Fri, Mar 4, 2016 at 9:26 PM, James Fuller <jim@webcomposite.com> wrote:
> I was a little unsure of just what has been decided ... does this fit
> your current assumptions?
>
> -------------------
>
> xproc version = "2.0";
>
> inputs: $source as document-node()
> outputs: $result as document-node()
>
> declare option p:exclude-inline-prefixes="my c p"
>
> declare option language
> declare option match
> declare option attr
>
> declare flow my:dyer
>   inputs: $source as document-node()
>   outputs: $result as document-node()
> ($langage as xs:string,
>  $match as xs:string,
>  $attr as xs:string
> ){
> $source → replace($match) {
>   projection(template("/*/@{($attr)}")) ≫ $ca
>   { if($lex($ca))
>          then xquery(template("attribute {($attr)} {( $lex($ca) )}")
>          else $ca }
>   } ≫ $result
> }
>
> p:load(href="{$language}.json",override-content-type="application/json")?colourMap
> ≫ $lexmap
>
> $source →
>   my:dyer(match=$match,lex=$lexmap,attr=$attr) ≫ $result
>
> On 5 March 2016 at 01:16, Alex Miłowski <alex@milowski.com> wrote:
>> As Henry pointed out in the original proposal, you can't have the same
>> name (or syntax in this case) for the defaulted input and output port
>> of a block expression.  There is little difference between:
>>
>> { [] → magic() → [] }
>>
>> and
>>
>> { $1 → magic() → $1 }
>>
>> and we decided the latter was not desirable.
>>
>> On Thu, Mar 3, 2016 at 8:16 AM, James Fuller <jim@webcomposite.com> wrote:
>>> redraft based on Alex suggestions (though I kept [] cause I do not
>>> think we are required to explicitly name)
>>>
>>> --------------
>>>
>>> xproc version = "2.0";
>>>
>>> inputs: $source as document-node()
>>> outputs: $result as document-node()
>>>
>>> declare option p:exclude-inline-prefixes="my c p"
>>>
>>> declare option language
>>> declare option match
>>> declare option attr
>>>
>>> declare flow my:dyer
>>>   inputs: $source as document-node()
>>>   outputs: $result as document-node()
>>> ($langage as xs:string,
>>>  $match as xs:string,
>>>  $attr as xs:string
>>> ){
>>> $source → replace($match) {
>>>   [] → projection(template("/*/@{($attr)}")) ≫ $ca
>>>   [] → { if($lex($ca))
>>>          then xquery(template("attribute {($attr)} {( $lex($ca) )}")
>>>          else $ca } ≫ []
>>>   } ≫ $result
>>> }
>>>
>>> p:load(href="{$language}.json",override-content-type="application/json")?colourMap
>>> ≫ $lexmap
>>>
>>> $source →
>>>   my:dyer(match=$match,lex=$lexmap,attr=$attr) ≫ $result
>>>
>>>
>>>
>>> On 3 March 2016 at 17:04, Alex Miłowski <alex@milowski.com> wrote:
>>>> I think we'll still want to have defined names for the replace
>>>> operation and probably want to treat it as a specialized step
>>>> invocation.  Within the block expression for the replace, we'd have a
>>>> default name for the input and output ports.
>>>>
>>>> Also, I wouldn't conflate data literals and projections.
>>>>
>>>> $source → replace($match) {
>>>>   $source → projection(template("/*/@{($attr)}")) ≫ $ca,
>>>>   $source → { if($lex($ca))
>>>>          then xquery(template("attribute {($attr)} {( $lex($ca) )}",
>>>> ... need variable mappings ...)
>>>>          else $ca } ≫ $result
>>>>   } ≫ $result
>>>> }
>>>>
>>>> Not sure about using xquery to construct an attribute node ...
>>>>
>>>> You can see how the choice of a common input port name can be
>>>> confusing.  $source is in a new scope within the block expression and
>>>> is bound to the item matched by replace.
>>>>
>>>>
>>>> On Thu, Mar 3, 2016 at 5:34 AM, James Fuller <jim@webcomposite.com> wrote:
>>>>> At yesterday's team meeting, Henry presented his work
>>>>>
>>>>>    https://github.com/xproc/notes/tree/master/design
>>>>>
>>>>> where he has authored non trivial xproc v1 and xproc v2 pipeline with
>>>>> the xml syntax to discover API semantics, which he has started to
>>>>> collect thoughts below:
>>>>>
>>>>>    https://rawgit.com/xproc/notes/master/design/xmpl.html
>>>>>
>>>>> These examples are an excellent 'proving ground' for the new flow
>>>>> syntax and I have attached below.
>>>>>
>>>>> As we are still discussing specifics of syntax and fleshing out how
>>>>> expressions may fit into the language I have taken some liberties and
>>>>> there are some glaring omissions.
>>>>>
>>>>> The flow syntax is easier to read and easier to follow 'flow' but we
>>>>> still have a bit of work to make things explicit. If we can get build
>>>>> up a corpus of such examples, they will serve us well as a guide for
>>>>> when we start speccing.
>>>>>
>>>>> J
>>>>>
>>>>> ---------------
>>>>>
>>>>> xproc version = "2.0";
>>>>>
>>>>> inputs: $source as document-node()
>>>>> outputs: $result as document-node()
>>>>>
>>>>> declare option output:exclude-inline-prefixes="my c p"
>>>>>
>>>>> declare %required option language
>>>>> declare %required option match
>>>>> declare %required option attr
>>>>>
>>>>> declare flow my:dyer
>>>>>   inputs: $source as document-node()
>>>>>   outputs: $result as document-node()
>>>>> ($langage as xs:string,
>>>>>  $match as xs:string,
>>>>>  $attr as xs:string
>>>>> ){
>>>>> $source → replace $match {
>>>>>   [] → data xml `/*/@{$attr}` ≫ $ca,
>>>>>   [] → { if($lex($ca))
>>>>>          then data xml `attribute $attr{ $lex($ca) }`
>>>>>          else . } ≫ []
>>>>>  } ≫ $result
>>>>> }
>>>>>
>>>>> p:load(href="{$language}.json",
>>>>> override-content-type="application/json")?colourMap ≫ $lexmap
>>>>>
>>>>> $source →
>>>>>   my:dyer(match={$match},lex={$lexmap},attr={$attr}) ≫ $result
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --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
>>>>
>>
>>
>>
>> --
>> --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
>>



-- 
--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, 11 March 2016 03:00:49 UTC