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: Jim Barnett <1jhbarnett@gmail.com>
Date: Fri, 31 Oct 2014 09:44:01 -0400
Message-ID: <54539221.7050708@gmail.com>
To: www-voice@w3.org
  You're right.  As long as the invoked process is a scxml session, you 
do not need to support more complex expressions for 'namelist'. The only 
requirement is that if an app passes you a full location expression (and 
the location exists in your datamodel), you should ignore it, rather 
than raising an error.

I will add a clarification to the section on invoking an SCXML session 
pointing out that the only thing that is required to be supported is an ID.

Perhaps I should have explained before that 'namelist' is in SCXML for 
partly historical reasons.  Both VXML and CCXML support it, and we 
assumed that a) a lot of people using SCXML would be familiar with those 
specs and b) that they would expect to find it in SCXML as well.

- Jim
On 10/30/2014 9:37 PM, Ate Douma wrote:
> 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 13:44:30 UTC

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