Constraining the xpath in the xpath attribute profile

["Cameron Morris" <cmorris@novell.com>]

		All,

Below you'll find Anne Anderson's comments on defining a constrained
XPath expression to uniquely identify nodes in an XML document.  Thanks
for the review and comments Anne.

First, not restricting XPath does not invalidate caching of XPath
attributes.  It does mean that redundant information can exist in a
cache.  This makes a cache less effective, but not ineffective. 

Second, I feel that constraining the xpath is a rat-hole that would
take too much effort.  Thanks to everyone's feedback, the current
profile satisfies everything I wanted to accomplish;  And it is simple
and small.  I'm afraid that constraining the xpath would make the
profile much more complex.

- Cameron
 
>>> Anne Anderson <Anne.Anderson@sun.com> 08/16/05 9:21 am >>> 
I would like to see more encouragement for constrained XPath
expressions
that allow a given nodeset to be uniquely identified by an XPath
expression.  Not all nodesets can be so uniquely identified, but nodes
used as "attributes" in Liberty and other use cases seem to be
uniquely
identifiable.  The current version of the XPath Attribute Profile
(Draft
#6, 16 August) says that "An Attribute Authority MAY constrain the
allowable XPath expressions.", but there is no mention of constrained
sets in Section 2.4 Interoperability.  I would like to say "An
Attribute
Authority SHOULD constrain the allowable XPath expressions to a set
providing unique references to given attributes in a document."

Without such a constrained set of XPath expressions, two entities may
reference the same attribute in a document, but will be unable to tell
that their references match the same nodeset.  This can be an issue in
caching attribute values and in matching required attributes between
entity policies.  This could be mentioned in the Interoperability
section to motivate the need for constrained expressions.

It would also be useful if some guidance were provided on which
constrained sets provide unique identifiers.  I believe that requiring
absolute paths (including no internal relative path components such as
/../) and prohibiting XPath query operators and element order
specifiers
([<digit>]) is sufficient, but I have no proof.  These constraints may
also be overly strict.  If anyone can apply some theory to this
problem,
it would be valuable.

Anne Anderson


cmorris@novell.com wrote:
> Changes:
> -  Added Greg Whitehead's suggestion of using normative notation:
MUST,
> SHOULD, etc..
> -  Added Rich Salz's clarification of the location of xmlns
> -  Added inline schema of ResourceIndicator
> -  Clarified support of text nodes as "SHOULD"
> -  Clarified support of text nodes of Liberty Web services as "MUST"
> 
>  --  Mr Cameron Morris
> 
> The document revision named draft- saml- xpath- attribute- profile-
05.sxw
> (draft- saml- xpath- attribute- profile- 05.sxw) has been submitted
by Mr
> Cameron Morris to the OASIS Security Services (SAML) TC document
> repository.  This document is revision #6 of
> sstc- saml- 2.0- xpath- attribute- profile- draft.sxw.
> 
> Document Description:
> This profiles the use of SAML attributes for xPath queries as
attribute
> names.  This allows parts of XML documents and Web services (Such as
> Liberty  data services) to be referenced in attribute statements and
> attribute queries.
> 
> View Document Details:
> http://www.oasis-
open.org/apps/org/workgroup/security/document.php?document_id=14044
> 
> Download Document:  
> http://www.oasis-
open.org/apps/org/workgroup/security/download.php/14044/draft- saml-
xpath- attribute- profile- 05.sxw
> 
> Revision:
> This document is revision #6 of
> sstc- saml- 2.0- xpath- attribute- profile- draft.sxw.  The document
details page
> referenced above will show the complete revision history.
> 
> 
> PLEASE NOTE:  If the above links do not work for you, your email
application
> may be breaking the link into two pieces.  You may be able to copy
and paste
> the entire link address into the address field of your web browser.
> 
> - OASIS Open Administration

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