RE: [xacml-users] AttributeSelector usage

["Daniel Engovatov" <dengovatov@bea.com>]

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;
> 
>