[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-users] Reg. <ResourceContent>
Well frankly what I would have preferred is having some predefined buckets maybe like : <Request> <SubjectContent>...</SubjectContent> <ResourceContent>...</ResourceContent> <ActionContent>...</ActionContent> <EnvironmentContent>...</EnvironmentContent> </Request> Then use AttributeSelector that supported retrieving both text (attribute, cdata, etc) and elements that also takes in the datatype for the XPath - thus retaining typing. It lowers the barrier to support XACML and would have kept things very simple in my mind - but then again I maybe wrong:-) prakash On Wed, 30 Mar 2005 22:25:09 -0500, Seth Proctor <Seth.Proctor@sun.com> wrote: > > On Mar 30, 2005, at 10:12 PM, Daniel Engovatov wrote: > >> In general, however, I think this is > >> cleaner than defining a catch-all section where you can dump > >> XML-encoded data. That's just my opinion.. > > > > Actually, IMHO, a catch-all section for the context representation is a > > very good idea. Just stick it separately from Resource and name it > > <CONTENT>. > > I think you conflated two ideas here. I was talking about taking the > existing structure, but adding a section to Subject, Action, and > Environment that lets you dump _XML_ data. I don't like this idea. I > was not talking about changing the complete context representation. > > > Getting down that road - Subject, Action etc are not really needed > > either. They are just for ease of management. Should be just some, > > maybe predefined, extensible "buckets" - to associate with various data > > sources. :) > > They're not needed, but I think they're very useful in practice. "Ease > of management" should not be taken lightly :) > > > seth > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]