- From: Jim Barnett <jim.barnett@genesys.com>
- Date: Tue, 28 Oct 2014 14:20:02 +0000
- To: Ate Douma <ate@douma.nu>, "www-voice@w3.org" <www-voice@w3.org>
Ate, I think that clarifications that you propose make sense, and I will add them to the spec. I think that it also makes sense to add a further clarification that the "write back" or "application" is done "as if by <assign>". For the XPath data model that would mean that it was done as "replacechildren". Applications that want to do another kind of assignment can always do it in two steps: write the returned value to a temporary location and then do an explicit <assign>. - Jim -----Original Message----- From: Ate Douma [mailto:ate@douma.nu] Sent: Tuesday, October 28, 2014 10:02 AM To: www-voice@w3.org Subject: Re: [SCXML] Question regarding the meaning and purpose of type 'location expression in namelist and param location attributes On 28-10-14 10:39, David Junger wrote: > Le 28 okt 2014 à 03:31, Ate Douma <ate@douma.nu> a écrit : >> >> 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? > > Yes, the location expression itself matters when you use 'location' > rather than 'value'. It is tied to the use of empty <finalize/> when > receiving events back from the invocation: in that case, params sent > back with the name assigned to of one of the locations on starting the > invocation will have their value copied into that location. I don't > recall that there is any other use, and that one is pretty marginal. > But the definition clearly states that a location expression can be > any valid left-hand-side value in the ECMAScript datamodel. The tests do not currently check for full conformance with this. > They should use a different name and location, for starters. And they > should check that params with a name that wasn't associated with a > location in the <invoke> are not copied. > > . or we could just drop this pretty complex, obscure, and marginal feature. Thanks David, that indeed is an obscure but valid use-case, at least for now :) This use-case and the (only?) reason for using the location attribute clearly can use so more explicit wording in the specification IMO: in the context of the <param> element, as well as the main body of the description of the <invoke> element. Right now the only place this seems to be described is in the <finalize> element. I suggest at least changing the description for the <param> location attribute as something like: "A location expression [...] that specifies the location in the datamodel to retrieve the value from, and write back a value in case of processing returned data from an invoked child session with an empty <finalize/> in its <invoke> element". And something similar should be added to the description of the <invoke> namelist attribute. What also needs some further clarification is how a returned value from the invoked session should be 'applied' back to the original location, in case of the xpath datamodel. The operation seems to be similar like <assign>, but (for xpath) should it use type 'replace' or 'replacechildren'? For <assign> the default is 'replacechildren', but either might make sense for <finalize/> handling. The specification says nothing about that though. Kind regards, Ate > > David >
Received on Tuesday, 28 October 2014 14:20:34 UTC