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

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

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

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]