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

On 29-10-14 03:04, Jim Barnett wrote:
> Ate,
>    We're getting closer.  The statement about the attribute name matching a data
> model ID is in Section 6.4.3, which describes the behavior when the invoked
> session is itself an/_SCXML session_/. And, yes, in that case if you pass
> something other than an ID it may be ignored, except for the statement that
> "However the Processor /MAY/ make the values available by some other
> platform-specific means." (There's no way to write a test for "platform-specific
> means", of course.)
>
> But what if the invoked process is something other than an SCXML session?  The
> spec does not restrict the type of the invoked process, and there may well be
> process types for which location expressions (i.e., more complex than IDs) do
> make sense.  We don't want to restrict that behavior in the spec.  So allowing
> more general location expressions (i.e. in place of IDs) allows platforms
> flexibility to handle different types of invocation.
>
> We are trying to write a spec that allows a wide range of data models, Event I/O
> processors, and invocation types.   We do provide fairly precise instructions
> for what should happen in the specific case of an SCXML session invoking another
> one  (and we write tests for that case), but just because the use of a certain
> location expression isn't defined for that SCXML/SCXML  case doesn't mean it's
> useless in all other cases.
>
> There are many things that the spec allows that we cannot test directly, because
> we don't/can't define all the possible entities that one might invoke or send
> messages to.   We want to make sure that the spec language allows reasonable
> behavior in those cases, even if we cannot define what it is a priori.
>

Thanks Jim, and sorry for late follow up.

While I still don't like the 'blending' of an attribute 'name' (its called 
namelist for a reason, right) with a location expression from a modeling 
perspective, I acknowledge the fact that there might be use-cases which can make 
use of this. Although IMO even then it would be just as feasible and more 
appropriate to use <param> instead.

And, as I think this only applies to non SCXML target sessions, it should be 
perfectly fine for my implementation to not support this and only expect and 
accept 'raw' data IDs in a namelist. And I can still support these other 
use-cases with the <param> element.

So, while I think it would be better to clarify that a namelist for an <invoke> 
targeting an SCXML session is expected to contain 'raw' data IDs, I no longer 
consider it a serious problem for *my* implementation.

Kind regards,

Ate

> - Jim
>
> On 10/28/2014 8:32 PM, Ate Douma wrote:
>> On 29-10-14 01:20, Ate Douma wrote:
>>> On 28-10-14 23:48, Jim Barnett wrote:
>>>> 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.)
>>>
>>> I still disagree :)
>>>
>>> For <assign> this all makes perfectly sense but that is because it doesn't have
>>> a double edged requirement...
>>>
>>> The problem with namelist (but not when using a <param> instead) is that passing
>>> data to the invoked session does adds a second requirement to the validity of
>>> the attribute name.
>>>
>>> While "foo.bar" is a valid location expression it is not a valid ECMA data ID in
>>> the invoked session. Which is the second requirement for *delivery* of the
>>> attribute at the invoked session.
>>>
>>> With <param> this problem doesn't exist because it uses a separate name
>>> attribute (of type NMTOKEN) to indicate a data ID in the invoked session.
>>>
>>> And this problem is even more prominent when using an XPath datamodel:
>>>
>>>    <datamodel>
>>>      <data id="foo">
>>>        <bar>baz</bar>
>>>    </datamodel>
>>>
>>> An XPath namelist "foo/bar" cannot be used to deliver the attribute in the
>>> invoked session as that would require an XML illegal data ID like:
>>>
>>>    <datamodel>
>>>       <data id="foo/bar"/>
>>>    </datamodel>
>>>
>>> Hence for both XPath and ECMA (and in ALL cases when the invoking and invoked
>>> session use the same language) the only *usable* location expressions for an
>>> <invoke> namelist must be legal data ID values.
>>> Not so much for the invoking session but for the invoked session.
>>>
>>> Of course (only) if the invoking session uses ECMA and the invoked session
>>> XPath, then indeed <data id="foo.bar"/> would be feasible.
>>>
>>> But for only such limited use-cases: why make it more complex than really
>>> needed?
>>>
>>> Why not reserve the support for those use-cases with <param> and simplify the
>>> definition for namelist to a space-separated list of NMTOKENs?
>>>
>>> So IMO there is a very good reason not to use expression location as type for
>>> namelist while I still fail to recognize a good reason why it should.
>>
>> I'm curious: does anyone actually have a working SCXML implementation where
>> using an ECMA "foo.bar" namelist (or even better: the XPath "foo/bar"
>> namelist) works for passing the attribute to the invoked session?
>>
>> I fail to see how that can be implemented. Can we have an IRP test for this?
>>
>>
>>>
>>> Ate
>>>
>>>
>>>>
>>>> - 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>

Received on Friday, 31 October 2014 01:37:50 UTC