- From: Jim Barnett <1jhbarnett@gmail.com>
- Date: Fri, 31 Oct 2014 09:44:01 -0400
- To: www-voice@w3.org
Ate, 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