XPath issues and resolutions

I'm looking for some more feedback on recent changes to the XPath attribute profile: 
    

    

      http://www.oasis-open.org/apps/org/workgroup/security/download.php/12486/sstc-saml-2.0-xpath-attribute-profile-draft-02.pdf
    

    

      http://www.oasis-open.org/apps/org/workgroup/security/download.php/12484/sstc-saml-2.0-xpath-attribute-profile-draft-02.sxw
    

    
 

    

      Several issues with an XPath attribute profile were discussed with previous revisions.  To make sure these are resolved I thought I'd make a compilation of the issues and where I think they are at currently.  
    

    
 

    

      Here is a link for the use cases to get a feel for goals of the profile: http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00044.html
    

    
 

    

      Issue: Liberty's defined minimum subsets usually reference elements and not text nodes.  Yet, the use cases show that we are really after the text nodes
    

    

      From: Robert Aarts
    

    

      Email: http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00071.html
    

    

      Implementations now must support at a minimum absolute xpaths to text nodes.  This means appending "/text()" to the defined Liberty xpaths.
    

    
 

    

      Issue: Uniquely referencing attribute values with XPath - useful for caching
    

    

      From: Anne Anderson
    

    

      http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00023.html
    

    

      This is still a concern.  We don't want attribute consumers to have to know that much about the XML document.  To the SP an xpath attribute should be just like any other attribute.  If IDP's and SP's stick to the defined interoperable subset (absolute paths to text nodes) then caching should be OK.  There still can be some duplication of data inside the cache - but it shouldn't ever have incorrect data.  However, by not solving this problem we solve the next few issues.
    

    
 

    

      Issue: Use only uniquely identifying xpaths for asserted attributes but full xpath in queries.  This could result in multiple attributes(not just multiple values) returned for one attribute query
    

    

      From: Scott Cantor, Anne Anderson
    

    

      http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00034.html 
    

    

      This goes away if we relax the need for asserted attributes to by absolutely unique.  
    

    
 

    

      Issue: Trying to use XPath in the name with 'urn' name format
    

    

      From: Eve Maler, John Kemp, Robert Aarts, Rich Salz...
    

    

      email: http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00067.html
    

    

      http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00054.html
    

    

      http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00060.html
    

    

      http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00057.html
    

    

      ... and others
    

    

      The name format is now w3.org's URL for XPATH and the name is straight XPATH.  If we do not need unique xpaths then we don't have to state which xpath restriction we are using.
    

    
 

    

      Thanks,
    

    

      Cameron Morris