OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]