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] AttributeSelector usage

One reason that AttributeSelector is an optional feature and that it
atomizes the returned sequence is not to introduce XPath data model
dependencies and handling of Schema types into the standard.   (Which is
a good thing as the upcoming XPath 2.0 data model is bit different - and
quite improved.)

If you allow the selector to return any arbitrary XML type - where you
will get the type information?  Content is not required to have a
schema.  As for pointing into the request document - it is not supposed
to be a real XML document, so you can design efficient PDP API's.

I do not think it is limiting custom applications in any way.  There is
no reason to return an arbitrary type if it can not be an argument to a
function.  And if you introduce a new function that accepts a new type -
it is your responsibility to enhance the context handler to retrieve and
type checks those new types. This is abstracted away into the context,
or your new function using an AttributeDesignator.

Use Designators anyway. :)  



-----Original Message-----
From: Seth.Proctor@Sun.COM [mailto:Seth.Proctor@Sun.COM] 
Sent: Thursday, March 10, 2005 9:44 PM
To: Prakash Yamuna
Cc: Daniel Engovatov; Muhammad Masoom Alam;
Subject: Re: [xacml-users] AttributeSelector usage

Prakash Yamuna wrote:
> [...]
> Is this truly a spec restriction (or a bug in the implementation I am

Now wait a minute! :)

My reading of the spec is that, indeed, AttributeSelectors must convert 
the nodes they select, so no, you cannot select an element and use it 
(and its children) to represent some new datatype you've defined. Do I 
think this is limiting? Yes. I don't think it's too terrible, since you 
can always select on individual sub-elements, but I don't see why the 
spec needed to include this restriction.

Now, this said, I could be wrong. It would not be the first time on this

topic, since the spec has been remarkably incomplete or misleading in 
the past when it comes to the AttributeSelector element. This is part of

why I implemented the XPath handling of AttributeSelector in a separate 
module of my code. It makes it easy to include/exclude from a 
deployment, and it makes it much easier to replace with alternate 
implementations if needed. If you want to try implementing the support 
you're looking for, I'd be happy to help you figure this out, but I 
don't think it's teechnically compliant with the spec.


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