Re: [SCXML] Question regarding the meaning and purpose of type 'location expression in namelist and param location attributes

Ate,
   The second question that you pose here has already been addressed on 
the list.  The first question you pose is related, but I will address it 
separately for clarity: namelist is intended to be more general than 
just a data element ID.  In the general case, a data element ID may have 
as its value a complex tree structure (or something even more complex).  
The purpose of a location expression is to let you reach down into that 
structure and extract/pass/send a subtree, rather than the entire value 
of the data element. Section 5.9.2 tries to make this clear.   (It 
should not just refer to the <assign> element, though.  I will correct 
that.)

However we don't explain what we mean by the 'name' of a location 
anywhere.  The main reason that the definition of the datamodel manages 
to be so complex yet vague at the same time is that we are abstracting 
away from the underlying data language.  The vagueness of "location"  
and "name" is part of that abstraction.  We could try to come up with a 
suitably abstract definition of "name", but I think that it would be 
better (if less general) to remove "name" altogether and rephrase the 
Description of 'namelist' for both <send> and <invoke>:

for <send>:  "A space-separated list of location expressions that will 
be evaluated to produce list of attribute/value pairs to be included 
with the message.  In each attribute/value pair, the attribute will be 
the location expression itself, and the value will be the part of the 
data model stored at the location denoted by the location expression.  
See /5.9.2 Location Expressions/ <cid:part1.04080205.06030702@gmail.com> 
for details. "

for <invoke>:  ""A space-separated list of location expressions that 
will be evaluated to produce list of attribute/value pairs to be passed 
to the invoked process.  In each attribute/value pair, the attribute 
will be the location expression itself, and the value will be the part 
of the data model stored at the location denoted by the location 
expression.   See /6.4.4 Data Sharing/ 
<cid:part2.08040404.08040207@gmail.com> and /5.9.2 Location Expressions/ 
<cid:part1.04080205.06030702@gmail.com> for details. "

Does that seem OK to you?

- Jim

P.S. If we had picked a single language such as ECMAScript or XPath, the 
spec would be shorter and clearer, but less flexible.

On 10/27/2014 10:31 PM, Ate Douma wrote:
> Hi,
>
> I'm puzzled about the meaning and purpose of the type 'location 
> expression' for the <invoke> and <send> namelist attribute and the 
> <param> location attribute in the SCXML specification.
>
> The namelist attribute is described in the specification as
>
>   "A space-separated list of one or more data model locations to be 
> included as attribute/value pairs with the message."
>
> followed with
>
>   "(The name of the location is the attribute [...])".
>
> All the examples given in the specification as well as in the IPR 
> tests only make use of datamodel data id values as 'names'.
>
> If that is the (only) intended usage, why then should this be of type 
> 'location expression' and not more transparently typed as "data 
> element IDs"?
>
> On the other hand, if this really should be interpreted as dynamic 
> location expressions *yielding* a datamodel value, then "(The name of 
> the location is the attribute [...])" becomes a very complex one, 
> where only the result of the expression is a location for which the 
> 'name' has to be derived dynamically.
>
> Currently I presume the first interpretation is intended, but in any 
> case IMO the current type definition and description can use some 
> stronger clarification.
>
>
> And I have a somewhat related question concerning the purpose of and 
> distinction between the <param> expr and location attributes, which 
> are to be used mutually exclusive.
>
> The description for the <param> location attribute says:
>
>   "A location expression [...] that specifies the location in the 
> datamodel to use as the value."
>
> Taken literally, this actually means the location *itself* should be 
> passed as value, not the value *at* the location.
> But I don't think that is the intended purpose, right?
>
> AFAICT the purpose of the location attribute is only to yield the 
> value at the specified location, not the location itself.
> But then: why not just and only use the expr attribute always, which 
> should be giving the exact same result, if it targets a datamodel 
> location?
>
> Maybe there is some nuance I'm overlooking here, possibly particular 
> to certain expression languages, but AFAIK the intend for both the 
> expr and location attributes is or should be exactly the same: yield 
> the data value.
> So I'm missing the point why I ever would need to use (and therefore 
> need to implement) the location attribute.
>
> I hope I've described my confusion clearly enough :)
>
> Kind regards,
>
> Ate
>