[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Better description of Issue#57 XPath intersection problem
I still don't have a definitive solution to Issue#57, but at least I have entered a better description of the problem into the WIKI. Here it is for those who want to read it here: In Web Services, a Client and a Service Provider both have requirements for interaction, and we need to know if those requirements are compatible. At a minimum, we need to determine at least one specific set of parameter values that will satisfy both the Client's and the Service Provider's policies. Ideally, we want to determine a new policy that will accept exactly those sets of parameter values that would have been accepted by BOTH the original policies, and that will reject all other sets of parameter values. Making this determination is what we call "policy intersection." If the policy requirements refer to XML documents, at a minimum we need to determine at least one specific XML document that will satisfy both original policies. Ideally, we want a new policy that will accept all and only those XML documents that would be accepted by both original policies. WS-XACML allows the requirements in a Client or Service Provider policy to be expressed using a list of <Apply> functions that contain AttributeDesignators or AttributeSelectors. The <Apply> functions from each party specify the acceptable set of values for each parameter or "Attribute" to be used in the interaction. WS-XACML can efficiently create a new policy that meets the ideal requirements for policy intersection: for each Attribute, it specifies the set of values that is acceptable to both the Client and the Service Provider. From this new policy, it is easy to create one or more specific sets of Attribute values that will satisfy both parties. In comparing requirements where AttributeDesignators are used, WS-XACML knows that each AttributeId is associated with a unique parameter that does not overlap with any other parameters. WS-XACML thus compares the functions that apply to Attributes having the same AttributeId values. [By the way, this restriction to non-overlapping parameters applies to XACML in general. For example, if one Boolean AttributeId was defined to mean "isAManagerOrOfficer", and another Boolean AttributeId was defined to mean "isAManager", an XACML PDP would not be able to determine based only on the semantics it understands whether a Client who submitted a value of "True" for "isAManager" satisfied a policy that specified that "isAManagerOrOfficer" must be "True".] In comparing requirements where AttributeSelectors are used, WS-XACML runs into a problem: each XPath expression is not associated with a unique parameter, but instead with a "nodeset" - the set of nodes selected by the XPath expression in the various XML documents against which it is evaluated; the various nodes in the set may represent different parameters. It is possible that two different <Apply> functions using AttributeSelectors may specify some requirements that apply to the same nodes and some that apply to different nodes. So with unrestricted XPath expressions in AttributeSelectors, WS-XACML is unable to determine which <Apply> function requirements should be compared with which other <Apply> function requirements, and is also unable to determine exactly which XML documents would satisfy both (and only) the original sets of requirements. For this reason, we would like to define a restricted XPath syntax such that 1) Two XPath expressions match, for example as string values, if and only if they refer to exactly the same set of nodes in all input XML documents. 2) Two XPath expressions that do not match will never select any of the same nodes in any XML document. EXAMPLE ======= Take the following two XPath expressions: 1) /C/text() 2) //A/B/C/text() Take the following two Apply functions, representing requirements from two different Web Service policies: 1) <Apply> function with //A/B/C/text() <Apply FunctionId="integer-subset"> <AttributeSelector DataType="integer" RequestContextPath="//A/B/C/text()"/> <Apply FunctionId="integer-bag"> <AttributeValue DataType="integer">3</AttributeValue> <AttributeValue DataType="integer">4</AttributeValue> </Apply> </Apply> 2) <Apply> function with /C/text() <Apply FunctionId="integer-subset"> <AttributeSelector DataType="integer" RequestContextPath="/C/text()"/> <Apply FunctionId="integer-bag"> <AttributeValue DataType="integer">3</AttributeValue> <AttributeValue DataType="integer">4</AttributeValue> </Apply> </Apply> When these two <Apply> functions are evaluated against the following document, the two AttributeSelector elements select exactly the same nodes - those with values {3, 4} - and both functions evaluate to "True": Request ResourceContent A: <A> <B size="little"> <C>3</C> </B> <B size="big"> <C>4</C> </B> </A> When these two <Apply> functions are evaluated against the following document, however, the two AttributeSelector elements select overlapping nodes. "//A/B/C/text()" will select the nodes with values {3, 4} and will return "True". "/C/text()" will select the nodes with values {3, 4, 5} and will return "False". Request ResourceContent B: <A> <B size="little"> <C>3</C> </B> <B size="big"> <C>4</C> </B> <C>5</C> </A> Other known problems ==================== 1) Use of elements specified according to document order: e.g. //A/B[2]/C/text() would overlap with "//A/B/C/text()". 2) Use of relative path expressions: e.g. /B/../C/text() 3) Use of XML attribute match functions in the XPath expression: e.g. //A/B[@size="big"]/C/text() overlaps with "//A/B/C/text()". Regards, Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]