On Mar 30, 2005, at 9:32 PM, Prakash Yamuna wrote:
> Section 6.4 states:
> [...]
> The key phrase that struck me was - "notional placeholder for the
> content of the resource" - hence my assumption that <ResourceContent>
> can be used only for xml content representation of resources.
Your assumption is correct. Sort of. The ResourceContent element is the
standard place to include some or all of the content (ie, the resource)
that you're trying to access. Since it's being provided in XML
(typically), the content must be represented here in XML. That does not
mean, of course, that the original document must be in XML. It only
means that it must be representable here (as you say) in XML, so that
it can be queried. For that matter, the context does not physically
need to be XML, it just needs to hold to the required semantics, but in
practice the Request is often an XML document.
What's the point? You may want to include rules in your policy that are
based on elements of the resource being accessed. One way to do this is
with designators, and then you either include the values in your
Request or have some custom handler in your context (in my
implementation, this is called an AttributeFinderModule) to pull the
value from the document. In an XML world it may be more natural to use
XPath, so a selector can be used instead, and the normative place to
look for values is in the ResourceContent.
As Daniel said in his last email, there is no notion of a
SubjectAttributeSelector (etc.) since the ResourceContent values may be
applied as any kind of attribute.
Getting back to your original question, I'm not entirely sure I
understand where you're going. What would a SubjectContent look like?
Or are you trying to create a new place to hold arbitrary subject
attributes in structured XML?
seth
