This post is part of Issue 5’s answer
I’ve highlighted the relevant artifacts in the following excerpt of the WS-PolicyAssertions spec:
The contents of the <MessagePredicate> element is an XPath 1.0 expression. The XPath expression is evaluated against the S:Envelope element node to determine a true or false result. The expression SHOULD use the functions defined in Appendix I (where appropriate).
Appendix I. XPath Expressions for Policies
This section defines a set of normative functions for use with XPath [XPATH] to simplify the path expressions that may be used within assertions to reference message elements.
We define the evaluation context for the XPath expressions to be the document containing the SOAP envelope. The namespaces in use at the point of the assertion element containing the XPath expression automatically defined for the context of the XPath expression. We do not define any variables, but we do define the functions (which work across both SOAP 1.1 [SOAP11] and SOAP 1.2 [SOAP12]) described below.
This function returns the SOAP envelope <S:Body> element from
the specified Envelope element.
This function returns true if the specified node is in the SOAP envelope <S:Body> element from the specified Envelope element.
This function returns the SOAP envelop <S:Header> element from the specified Envelope element.
The following example illustrates the use of this declaration. In this example, the messages to which this assertion applies must contain exactly one WS-Security <Security> header element.
count(wsp:GetHeader(.)/wsse:Security) = 1
Applying this to our problem, the MessagePredicate will look the following:
wsp:GetBody(.)/here/goes/my/path > 4