[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] xpath datatype and collision with the hierarchical resources profile
One issue to keep an eye on - there are no nodesets in Xpath2.0. It returns an XDM instance. I think we need to define a mapping into atomic XACML datatypes on a lowest possible level when executing an XPath expression, probably using atomization semantics (http://www.w3.org/TR/xpath20/#id-atomization); not retuning nodesets. Of course we would need to fomally define mapping from XPath type hierarchy (http://www.w3.org/TR/xpath-datamodel/#types-hierarchy) into XACML atomic types. -----Original Message----- From: Erik Rissanen [mailto:email@example.com] Sent: Friday, June 08, 2007 4:27 AM To: xacml Subject: [xacml] xpath datatype and collision with the hierarchical resources profile All, Remember that we decided to include an explicit xpath datatype for 3.0 to solve issues with namespace resolving in xpaths if they are represented by simple strings? There is already a datatype called xpath-expression in the hierarchical resources profile. It does something completely different. It selects a nodeset from the <ResourceContent>. When we introduce the new xpath datatype for 3.0, we have at least these alternatives: 1. Call the new datatype ...-3.0-... and keep the existing datatype as well. I don't like this. I am worried about having two datatypes with almost identical names, except one called ...-2.0-... and the other ...-3.0-..., where they have completely different behavior. 2. Give the new datatype a competely different name. The trouble here is that I cannot think of a good name. And it will look silly to have the old thing called "xpath-expression", although it isn't, and the new thing is called something else. 3. Rename the datatype in the hierarchical resources profile. Call it "nodeset-by-xpath" or such. 4. Drop the datatype in the hierarchical resources profile. It's not really a datatype, rather a function. Instead we define a function which takes an xpath as a parameter (in the form of the new 3.0 xpath datatype) and returns a nodeset selected from a <Content> document (indicated by a second parameter). I prefer alternative 4. I think we need to break this in some way in any case since there is not a single <ResourceContent> anymore, so we need to add the second parameter to select the attribute category of the <Content> element. This makes the whole thing look even more like a function. Regards, Erik Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.