- From: Jim Barnett <1jhbarnett@gmail.com>
- Date: Tue, 28 Oct 2014 22:04:39 -0400
- To: www-voice@w3.org
- Message-ID: <54504B37.5090906@gmail.com>
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. - 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 Wednesday, 29 October 2014 02:05:09 UTC