- From: Ate Douma <ate@douma.nu>
- Date: Fri, 31 Oct 2014 02:37:22 +0100
- To: www-voice@w3.org
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 01:37:50 UTC