- From: Ate Douma <ate@douma.nu>
- Date: Wed, 29 Oct 2014 01:32:01 +0100
- To: www-voice@w3.org
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 00:32:30 UTC