we have discussed this before, but there are implications in terms of an API version, worth a re-discuss.

It would be nice to provide annotations as well.

If you have two step chains, how do you say that one must run before the other (because of side-effects, not because of flow connections)

We could go as far as:

data(LHS,RHS) "media-type" DELIM
  Whatever you want LHS 3+4 RHS goes here.
DELIM

Do we have higher-order steps/functions

(: comment, a la XQuery? :)

to eol

// to eol

I think I lean towards one of the "to eol" flavors.

xml to csv

<address xmlns="http://www.example.org/address" id="1">
    <name>Ola Nordmann</name>
    <address>Langgt 23</address>
    <city>4000 Stavanger</city>
    <country>Norway</country>
</address>

namespace "http://www.example.org/address";

("some.xml")
-> text{ {$_/@id},{$_/name},{$_/country}}

should yield

1,"Ola Nordmann","Norway"

though this works only if each document is an xml document with an address root.

Its an open question about how to handle 'foreach' in these scenarios or if we are able to perform xpath filter on the input, like the following:

("some.xml")/address

Which is roughly equivalent to old syntax @select on p:input.

csv to xml

GID,Name,Country
1,Henry,UK
2,Alex,USA

namespace "http://www.example.org/address";

("some.csv")
-> ?

How can we make text selection easier in this scenario to yield the following ?

<wrapper xmlns="http://www.example.org/address">
<address id="1">
<name>Henry</name>
<country>UK</country>
</address>
<address id="2">
<name>Alex</name>
<country>USA</country>
</address>
</wrapper>

We can imagine other conversion scenarios that pose similar questions:

• triples to xml
• xml to triples
• json to xml
• xml to json

as well as questions surrounding 'exclude-inline-prefixes' and what 'expand-text' may mean in our new syntax. I propose we add this to next meeting agenda item.

The Replacement syntax appears to assume that the input document can be manipulated with XPath. This seems to be similar to Norm's concerns about projections.

In XProc2, steps don't have output bindings. Steps have outputs that are chained to following steps in step chains. At the end of a step chain, outputs can be bound to variables.

cnp'ed from email from @htInEdin

I understood someone (who?) to say something along the lines of: "I'd
like an API I could use to get a pipeline built".

That happens to fit pretty well with the way I've been trying to address
the 'abstract semantics' problem. And at lunch today, where I ended up
with Mohamed, Romain, Florent and John Snelson, we had a useful
discussion about possible language architectures, i.e. how many
languages do we have, and what's their relationship.

We came up with at least the following possibilities:

1. The XML syntax defines the language, there is a read-only textual
   version;

2. The XML syntax defines the language, there is an executable textual
   syntax, but it's not normative nor is support required for
   conformance (this was asserted to be the RNG/RNC story);

3. The compact syntax is normative, it maps to an XML language which
   defines the semantics but is not optimised for human-readability
   (this could be sort of Vnext as we had been working towards it,
   perhaps w/o (much) defaulting);

4. The compact syntax is normative, it maps to a set of logical
   assertions/object creation calls which defines the semantics, and
   which in turn has an XML syntax (what I think I heard from the
   floor).

Wrt the very preliminary way I've been going about this, here's what (4)
would look like for a trivial example:

s1 == StepImpl(p:load,uri="somedoc.xml")
s2 == StepImpl(p:data,type="application/xml",data="")
s3 == StepImpl(p:set-attributes,match="//*[@colour='red']")
s4 == StepImpl(p:serialize)
p1 == Pipe(s1.result,s3.source)
p2 == Pipe(s2.result,s3.attributes)
p3 == Pipe(s3.result,s4.source)

The XML for this is left as an exercise for the reader.

xs:string("string")
xs:integer("35")
etc.

Instead of

source=$in -> xslt(...)
[source=$in,stylesheet=$style] -> xslt(...)

Henry suggests

$in -> source@xslt(...)
[$in,$style] -> [source,style]@xslt(...)

Moving the assignment to the right hand side.

Do steps only run when they have to?

Do steps always run?

If they always run, what does it mean if they don't get any input

Need to tease out semantics for default context within {}

$in -> { .... what is the default context here ? .... }

There's confusion about the scope of iteration when it's an operator.

step() ! { some-chain }

vs

step() -> { foreach some-chain }

One possibility is that >> "literal.xml" at the end of a chain stores to "literal.xml".

Another possibility is that you have to say -> store("literal.xml").