Re: [xacml-users] AttributeSelector usage

[Prakash Yamuna <techpy@gmail.com>]

I mean i am amazed that I haven't been able to convince people this is
broken yet!

Here is an example that illustrates what I am saying:

<Request>
 <Subject>
    <Attribute AttributeId="myattrid" DataType="mydatatype">
    <AttributeValue>
       <myComplexElement attr1="value1" attr2="value2">
          <someotherelements/>
       </MyComplexElement>
     </AttributeValue>
 ...
  </Subject>
....
</Request>

This is ok! It works...
<Policy>
....
<Apply FuctionId="myfunction">
    <SubjctAttributeDesignator AttributeId="myattrid" DataType="mydatatype"/>
</Apply>

This is not ok! 

<Policy>
....
   <Apply FunctionId="myfunction">
      <AttributeSelector
RequestContextPath="//Request/Subject/Attribute[@attributeId="myattrid]/AttributeValue/myComplexElement"
DataType="mydatatype"/>
</Apply>
...
</Policy>

Do people see what I am talking about? 

If this is not broken - then I am not sure what else is!! Custom
datatypes, custom functions - but no deal! it won't work! because the
spec explicitly states this is not permitted!

I am not even getting into all the limitations surrounding typing!! 

That is a perma thread that has been going on various mailing lists
without me contributing to it...

prakash
On Tue, 15 Mar 2005 21:27:36 -0800, Prakash Yamuna <techpy@gmail.com> wrote:
> 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;
> > >
> > >
> >
> >
>