- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Thu, 08 Apr 2021 16:04:44 +0000
- To: Erik Bruchez <ebruchez@orbeon.com>
- Cc: XForms <public-xformsusers@w3.org>
- Message-Id: <1617897838720.259364862.967572229@cwi.nl>
In the last meeting, Erik said: Erik: In Orbeon, we do create a document … it was the easiest thing to do. So what are the advantages to it being a node-list, and what breaks if we change it? Steven On Friday 26 March 2021 09:58:06 (+01:00), Steven Pemberton wrote: Ah right. It's a shame really (from a user-consistency point of view) that it is different from how instance() works. In fact event('response-headers')[name = 'last-modified']/value isn't working for me, which I will further investigate, but event('response-headers')//[name = 'last-modified']/value is. Thanks. Steven On Thursday 25 March 2021 18:22:09 (+01:00), Erik Bruchez wrote: The spec says that event('response-headers') returns a `node-sequence`. So you have, in an informal way, using parentheses and commas to denote the sequence, something like this: ( <header> <name>last-modified</name> <value>Wed, 24 Mar 2021 02:26:50 GMT</value> </header> , <header> <name>content-type</name> <value>application/xml</value> </header> , etc. ) A sequence is similar to an array (although in XPath 3 arrays are something else yet!). So you could write: event('response-headers')[2] and this would, in the above case, return the `content-type` header element. But you cannot write: event('response-headers')/header because each item in the sequence doesn't have a `header` child element. It has `name` and `value` children elements only. The following might not work with all implementations, and arguably shouldn't: event('response-headers')/../header because it is assuming that all the elements in the sequence have a parent node and that it is the same parent node for all `header` elements. This is not required by the spec. The `header` elements can all be parent-less. Similarly, you cannot reliably write: event('response-headers')[1]/following-sibling::header because the elements are not required to be siblings (and probably should not be). To conclude, this is the correct and simple way to write your expression: event('response-headers')[name = 'last-modified']/value :) -Erik On Mon, Mar 22, 2021 at 3:40 AM Steven Pemberton <steven.pemberton@cwi.nl> wrote: Ok, so <setvalue ref="lm" value="event('response-headers')/../header[name='last-modified']/value"/> works as well. Not sure why the .. step is needed. Steven On Sunday 21 March 2021 21:04:46 (+01:00), Steven Pemberton wrote: > In a submit-done handler, is this really the best way to get to the "last-modified' header? > > <setvalue ref="lm" value="event('response-headers')/name[.='last-modified']/following-sibling::value"/> > > > I was rather disappointed that this didn't work: > > <setvalue ref="lm" value="event('response-headers')/header[name='last-modified']/value"/> > > Steven > --
Received on Thursday, 8 April 2021 16:05:00 UTC