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


Yes it is explicitly preventing you from accessing tree fragments.  As I
have tried to explain for quite some time - this is on purpose.

But nothing prevents you from accessing the request document or any
other document in any way you like and placing this information into the
context to be accessible using a designator, or to be returned from a
custom function that, for example, takes a path expression as an
argument.  AttributeSelector is NOT the way to do that.  

You would not complain that integer-add function does not brew coffee?
Why would AttributeSelector, that has very clear and concise semantics,
do something that is not designed to do?

You can fully achieve functionality that you need using XACML extension
points.  Other poster in this thread showed a good example on how one
can do that.

What is so hard to understand?

Daniel;


-----Original Message-----
From: Prakash Yamuna [mailto:techpy@gmail.com] 
Sent: Tuesday, March 15, 2005 9:28 PM
To: Daniel Engovatov
Cc: Seth.Proctor@sun.com; Muhammad Masoom Alam;
xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] AttributeSelector usage

I quote the spec on Atribute Selector:


"Each node selected by the specified XPath expression MUST be either a
text node, an attribute node, a processing instruction node or a
comment node. The string representation of the value of each node MUST
be converted to an attribute value of the specified data-type, and the
result of the AttributeSelector is the bag of the attribute values
generated from all the selected nodes.

If the node selected by the specified XPath expression is not one of
those listed above (i.e. a text node, an attribute node, a processing
instruction node or a comment node), then the result of the enclosing
policy SHALL be "Indeterminate" with a StatusCode value of
"urn:oasis:names:tc:xacml:1.0:status:syntax-error".

Where exactly does it say I can do what you specify? It explicity
prevents me accessing tree fragments!! Any conformant XACML
implementation has to return return "Indeterminate".

The door is closed shut for extensions!!

prakash
On Tue, 15 Mar 2005 11:06:38 -0800, Daniel Engovatov
<dengovatov@bea.com> wrote:
> While you do not care about that, I do not think it would be
appropriate
> for the XACML standard committee not to care about that.   Standard
has
> to be at least consistent and well defined.
> 
> Nobody prevents you from accessing a tree fragment (be it DOM, Xpath
> 1,0, XQuery 1.0/XPath 2.0 data model, XML infoset, XMLBean instance,
XML
> text fragment or whatever else).  In general - I would recommend using
> AttributeDesignator any time over Selector, and abstracting XML data
> type handling in you Context Handler.   Context handler was made into
a
> notional, abstract implementation dependent concept on purpose.
> 
> Daniel;
> 
> 
> -----Original Message-----
> From: Prakash Yamuna [mailto:techpy@gmail.com]
> Sent: Monday, March 14, 2005 11:39 AM
> To: Daniel Engovatov
> Cc: Seth.Proctor@sun.com; Muhammad Masoom Alam;
> xacml-users@lists.oasis-open.org
> Subject: Re: [xacml-users] AttributeSelector usage
> 
> I think we are splitting haris here! You are right in that XPath 1.0
> returns a node-set; I am not really concerned whether it is a DOM node
> or a node-set. The important point that was being made was any generic
> mechanism [potentially untyped:-) ] will do...
> 
> I can see the concern for typing...but all said and done - it boggles
> my mind that we have a tree fragment and we say one cannot access the
> entire tree fragment!
> 
> prakash
> On Mon, 14 Mar 2005 10:03:35 -0800, Daniel Engovatov
> <dengovatov@bea.com> wrote:
> > >Basically, it's a shame that you need to write a new function that
> acts
> >
> > >just like AttributeSelector for any new datatype you invent that is
> > >represented by mixed content in a DOM tree. On this point I agree.
> >
> > But I think you missed my point - XPath 1.0 does not return you a
DOM
> > tree - it returns a node-set defined on an abstract tree model
> > (http://www.w3.org/TR/xpath#data-model) with only non-normative
> mapping
> > to XML infoset.   XPath 2.0 data model will be better defined - and
> even
> > more different.
> >
> > This content will also have no type.  I think it is a strong part of
> > XACML that everything that comes out of context and into processing
> has
> > strict type.
> >
> > Importing this mess into our standard, for no reason other then
> > extensibility would be unwise, in my opinion.
> >
> > You also do not need to write a new function for each data type -
> write
> > one that computes a path expression and returns a node-set (or
> Boolean,
> > number or string, as XPath 1.0 can return) and add data-type
> "node-set".
> > But then it will be your responsibility to define what it really
means
> > and how it is type-checked.
> >
> > Daniel;
> >
> >
> 
>



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