W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2014

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

From: Ate Douma <ate@douma.nu>
Date: Wed, 29 Oct 2014 01:32:01 +0100
Message-ID: <54503581.8020505@douma.nu>
To: www-voice@w3.org
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 Wednesday, 29 October 2014 00:32:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:45 UTC