[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]