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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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

Subject: RE: [xacml-users] Reg. <ResourceContent>

I am not sure how imposing additional structural complexity will "lower
the barrier to support XACML" :)

Oh, well.  We have what we have now - for 3.0 this may be considered,
but I would speculate that having a single XML content root will have
more support.


-----Original Message-----
From: Prakash Yamuna [mailto:techpy@gmail.com] 
Sent: Wednesday, March 30, 2005 7:36 PM
To: Seth Proctor
Cc: Daniel Engovatov; xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Reg. <ResourceContent>

Well frankly what I would have preferred is having some predefined
buckets maybe like :


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


On Wed, 30 Mar 2005 22:25:09 -0500, Seth Proctor <Seth.Proctor@sun.com>
> 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
> > 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]