Re: flow example from Henry's work

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
>

Received on Thursday, 3 March 2016 16:16:33 UTC