RE: [xacml] The <ResourceContent> element again

["Daniel Engovatov" <dengovatov@bea.com>]

IIRC the idea of "id" was to be able to select a particular <Content>.
For example for a multiple resources profile, "id" could be equal to the
"resource-id" and content could be either selected with a
/Request/Content[@id = resource-id] path, or better yet - content node
(the "." in Xpath) could be set to the particular element as a root for
selector.

If this is moved back into the <Attributes> I do believe that id is not
needed anymore.   I also see no need for more then a single optional
<Content> element.

One way to make this mess a little bit more user friendly could be to
introduce an extension Xpath function that selects content for the
current resource id.   One Can then write
xacml:resource-content()/my/path[use].

That also reminds me that now XPath2.0 is a W3C recommendation and XACML
3.0 should probably introduce XPath2.0 for selectors, define levels of
support and define all the necessary environment settings for its use.
It would probably help if we define type mappings from XPath2.0/Schema
types into XACML types.

Daniel;

-----Original Message-----
From: Erik Rissanen [mailto:mirty@sics.se] 
Sent: Monday, February 19, 2007 11:42 PM
To: xacml@lists.oasis-open.org
Subject: [xacml] The <ResourceContent> element again

All,

I moved the element formerly known as <ResourceContent> inside the
<Attributes> element and added anyAttributes to it, to make it backwards
compatible, as discussed during the meeting.

There is one small issue still which I encountered. According to
Daniel's proposal, the <Content> element contains an XML attribute
called "id" which is required. An attribute selector may use this
attribute to refer to the <Content> element. There was no such id
attribute in 2.0, so I made it optional, or otherwise, when translating
2.0 policies, we would have to generate dummy ids which won't be used,
which is a bit ugly in my opinion.

Another thing I was thinking about: Should we allow multiple <Content>
elements in a single category? In 2.0 only one <ResourceContent> element
was allowed. If we allow only one <Content> element, now that the
<Content> element is inside the <Attributes> element, it is identified
by the category of the <Attributes> element, so the id attribute is not
really needed. (Thought it is still useful in the attribute selector, to
select a document from an implementation specific source, as proposed by
Daniel.) Actually, it is strictly not needed in any case, since it is
possible to match on any XML attribute in an XPath expression.

For now I am writing it so only one <Content> element per <Attributes>
element is allowed and the id attribute is optional. It is a functional
requirement that the <AttributeSelector> searches the request for the id
elements.

Let me know if you disagree.

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.