Re: flow example from Henry's work

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
>

Received on Saturday, 5 March 2016 05:26:34 UTC