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:20:56 +0100
Message-ID: <545032E8.4020804@douma.nu>
To: www-voice@w3.org
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:

     <data id="foo">

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:

      <data id="foo/bar"/>

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.


> - 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:21:25 UTC

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