Clarify row data flow mechanism and key/value pairings

[arcanefoam]

I am confused about the dataflow mechanims and what is the meaning/interpretation of ket/value parings, perhaps because there is no direct match between properties in the syntax metamodel *Figure 1) and the textual example (listing 1). My questions are: Does the key/value parings are the attribute and values of the different Elemets or are the the objects in each row? Is a row a collection, and each position in the collection holds a set of key/value pairs? E.g. What is the output of this rule? AllInstances AllMembers { field member type Families!Member target ComputeFullName } Each object in the row collection has a tuple "field":EObject ? And then when Evaluate ComputeFullName { field fullName expression member.firstName + ’ ’ + member.eContainer.lastName target SplitByGender } Executes then do you add a "fullName": tuple to each element in the collection? So following rules have acces to this set of key?value pairs?

I think it would be good to separete Elements that add properties to this "map" of attributes of each object in the row collection and Elements that only access them (e.g. the field attribute should be common to these and imply this porperty addition).

[agarciadom]

Rows are sets of fields: a field is a particular key+value pair.

You're right, this produces a collection of {member: EObject} rows:

AllInstances AllMembers {
field member
type Families!Member
target ComputeFullName
}

And this adds a fullName: String tuple to each of the incoming rows (so they'd be {member: EObject, fullName: String}):

Evaluate ComputeFullName {
field fullName
expression member.firstName + ’ ’ + member.eContainer.lastName
target SplitByGender
}

The idea of the textual syntax was to simplify over all these slightly different *field names when writing the spec manually, but you're right in that it wasn't the most obvious when reading. I'll mention this fact in the concrete syntax part of the description and provide the alternate categorization that you suggest.

[agarciadom]

I've added a paragraph explaining this detail about the *field bits. Actually, it's not about whether they modify or not the row, but rather it's just when the primitive takes only one field name (in which case we simply use field in the DSL) or multiple (in which case we use exactly the name in the metamodel).

I've also mentioned for each primitive if it's required by the later tasks or not, as some people are a bit scared of seeing so many primitives :-D.