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

Ate,

A location expression does not (in the general case) yield a value of 
type "ID" If we have (in ECMA) <data id="foo" value="bar.baz">, then 
"foo" is an ID (it is of XML Schema type "ID" in the document). However 
"foo.bar" is not an ID, but it is a valid location expression.The 
current language referring to the "name" of the data model location is 
vague.I am proposing to make it precise by saying that the location 
expression itself (i.e. the string "foo.bar") is passed as the attribute 
in the attribute/value pair (if the app has namelist="foo.bar", then the 
interpreter should pass the string "foo.bar" as the attribute and "baz" 
as the value).I think that's precise and easy to implement.


We may need to add a clarification to the ECMA and XPath data models 
that bare IDs are valid location expressions.  This does follow from the 
definitions of location expressions in the two data models, and there 
are examples showing that this is the case, but perhaps some extra prose 
would help.


Basically, location expressions have an ID at the root (i.e., something 
that was the value of the 'id' attribute of a <data> element), but may 
reach down inside the value that is assigned to the 'id'.  We definitely 
need this for <assign> to work properly, so I don't see any reason not 
to use it in 'namelist' and <param> as well (as long as we make it clear 
exactly what gets passed as the attribute name.)

- Jim

On 10/28/2014 6:07 PM, Ate Douma wrote:
> 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
>>>
>>
>
>