Re: [xacml-users] AttributeSelector usage

[Prakash Yamuna <techpy@gmail.com>]

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