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

On 28-10-14 16:31, Jim Barnett wrote:
> 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/
> 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/
> and /5.9.2 Location Expressions/
> for details. "
>
> Does that seem OK to you?

Not really.

Section "6.4.3 Implementation of <invoke>" explicitly states that:

   "If the value of a key in the namelist matches the 'id' of a <data> element 
in the top-level data model of the invoked session, the SCXML Processor must use 
the value of the key as the initial value of the corresponding <data> element."

So IMO the namelist elements can either:
- Be of type ID, targeting a root datamodel data id in the invoked session.
or
- Be a location expression which besides a value <em>also</em> yields a name of 
type ID. Somehow...

The latter option still doesn't make sense to me, and using even more vague 
wording doesn't make that go away.

Why can't we simply state that the names within the namelist *must* be of type ID?
I still don't see how that would be limiting for any use-case at all, regardless 
what datamodel language.
If the data to be passed on to the invoked session is located in some subtree, 
then you can use the <param> element. And for any other case using data IDs 
should be fine, and then you can use the namelist attribute for that (or even 
then the <param> element).

IMO it will make this all much clearer, easier to implement, and without any 
trade off or limitation.

Ate

>
> - 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
>>
>

Received on Tuesday, 28 October 2014 22:08:22 UTC