Re: Response headers

XPath 1.0 does not allow a predicate to be applied to a function call and current XSLTForms release still works with XPath 1.0 only. This will be different in the next XSLTForms release which will come with XPath 3.0!
I think XPath 1.0 does allow it, 


 FilterExpr  ::= PrimaryExpr 
     |   FilterExpr Predicate
 PrimaryExpr ::= FunctionCall 
 Predicate      ::=  '[' PredicateExpr ']'


 https://www.w3.org/TR/1999/REC-xpath-19991116/#NT-FilterExpr


but anyway, good news about the next XSLTForms!


Best wishes,


Steven






--Alain 
Le 26/03/2021 09:58, Steven Pemberton <steven.pemberton@cwi.nl> a écrit :




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
 >
--