RE: [xacml] xpath-expression datatype

[Anne Anderson <Anne.Anderson@Sun.COM>]

On 26 August, Seth Proctor writes: RE: [xacml] xpath-expression datatype
 > > > Separate from that, I think it's really late in the game to talk about
 > > > breaking compatibility with these functions.
 > > 
 > > That's right. Changing them would break backwards compatibility.
 > > 
 > > However, it would still be nice to have functions that took restricted
 > > types for arguments so that they may be type checked.
 > 
 > I agree. I think this is part of the recent discussions around IP
 > addreses, regexp expressions, etc. too. 
 > 
 > > > I do not think we should change the parameters now,
 > > 
 > > Agreed.
 > 
 > Ok.

I agree that we should not break backwards compatibility with
existing functions.  Yet I think "string to be interpreted as an
XPath expression" does not give implementers or policy writers
sufficient type checking capability.  I can also see extension
functions defined that would use an "xpath-expression" datatype,
and those would not necessarily be for hierarchical resources.

I suggest we extend the definition of the existing XPath-based
functions in A.3.14 to accept EITHER "...#string" OR
"...:xpath-expression", and indicate that "...#string" is
deprecated.  And then leave the definition of the
"...:xpath-expression" datatype in the core specification.  This
does not break backwards compatibility.

Another option would be to re-define the XPath-based functions in
A.3.14 with new identifiers: urn:oasis:names:gc:xacml:2.0:...,
and then change the definitions to use "...:xpath-expression".
Then 2.0 implementations that are backwards compatible can
continue to support the 1.0 versions, but the 2.0 versions can be
strongly typed.

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