RE: [xacml-users] AttributeSelector usage

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

There are no standard XACML functions that deal with tree fragments.
So, why would you expect other implementations to provide them?

XACML chose not to standardize handling of XML tree fragments (all
multitude of way to present them that I cited).  There are too many
unclear standards to choose from for this and we would not be able to
satisfy everybody anyway.  It should not be XACML business to define
context data bindings - for the explicit purpose that it can be used in
diverse environments.
 
I think what you are missing is that it is not one access control
language standard job to provide recipes on how to bind your enterprise
data sources.
XACML provides clear, simple interface to that data, with clearly
defined semantics on how it would use it.  It also provides a clear way
to extend its functionality. I find it is a superior approach to kitchen
sink way of loosely redefining everything.  

> Then I don't have too much choice do I?

Yes you do not.  In exchange you get a well defined behavior that can be
successfully implemented in a variety of environments, without worries
what flavors of xpath, schema etc. are implemented.   You can achieve
compatibility by a) representing all you data as named atomic values in
context, not as structured data types, b) defining those new structured
data types along with ways to validate them in every environment that
you utilize.

I do not believe it is feasible or wise for a standard to do the b)
option for you.  

Daniel;

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

Daniel,

It is not that I don't care about datatypes - I do and I have gone
ahead using AttributeDesignator as you recommended in one of your
earlier mails.

Not all XACML implementations are open source! Where I can go in and
change things to my needs!

If the spec says the XPath in AttributeSelector has to point to an
attribute node, etc or a string representation of the node - then I
don't have too much choice do I? Unless the vendor has defined some
custom mechanisms?

It is not exactly as though I a user of an XACML implementaton has the
choice to make!

Am I missing something in my understanding?

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