Re: [xacml-users] AttributeSelector usage

[Prakash Yamuna <techpy@gmail.com>]

Hmm -  that does put things in perspective a bit better - but I think
it would have been good to say here is an untyped DOM node and the
function can validate the type!. Not too much benefit in restricting
it to be atomic types!

That way the content handler wouldn't have to change...just because
different XPath's selected different typed nodes.

prakash
On Fri, 11 Mar 2005 11:01:39 -0800, Daniel Engovatov <dengovatov@bea.com> wrote:
> 
> One reason that AttributeSelector is an optional feature and that it
> atomizes the returned sequence is not to introduce XPath data model
> dependencies and handling of Schema types into the standard.   (Which is
> a good thing as the upcoming XPath 2.0 data model is bit different - and
> quite improved.)
> 
> If you allow the selector to return any arbitrary XML type - where you
> will get the type information?  Content is not required to have a
> schema.  As for pointing into the request document - it is not supposed
> to be a real XML document, so you can design efficient PDP API's.
> 
> I do not think it is limiting custom applications in any way.  There is
> no reason to return an arbitrary type if it can not be an argument to a
> function.  And if you introduce a new function that accepts a new type -
> it is your responsibility to enhance the context handler to retrieve and
> type checks those new types. This is abstracted away into the context,
> or your new function using an AttributeDesignator.
> 
> Use Designators anyway. :)
> 
> D;
> 
> my_special_function_that_understands_XML_data_model(my_node_retriever(at
> tribute_value("path/to/some/arbitrary/node"))
> 
> 
> -----Original Message-----
> From: Seth.Proctor@Sun.COM [mailto:Seth.Proctor@Sun.COM]
> Sent: Thursday, March 10, 2005 9:44 PM
> To: Prakash Yamuna
> Cc: Daniel Engovatov; Muhammad Masoom Alam;
> xacml-users@lists.oasis-open.org
> Subject: Re: [xacml-users] AttributeSelector usage
> 
> Prakash Yamuna wrote:
> > [...]
> >
> > Is this truly a spec restriction (or a bug in the implementation I am
> using)?
> 
> Now wait a minute! :)
> 
> My reading of the spec is that, indeed, AttributeSelectors must convert
> the nodes they select, so no, you cannot select an element and use it
> (and its children) to represent some new datatype you've defined. Do I
> think this is limiting? Yes. I don't think it's too terrible, since you
> can always select on individual sub-elements, but I don't see why the
> spec needed to include this restriction.
> 
> Now, this said, I could be wrong. It would not be the first time on this
> 
> topic, since the spec has been remarkably incomplete or misleading in
> the past when it comes to the AttributeSelector element. This is part of
> 
> why I implemented the XPath handling of AttributeSelector in a separate
> module of my code. It makes it easy to include/exclude from a
> deployment, and it makes it much easier to replace with alternate
> implementations if needed. If you want to try implementing the support
> you're looking for, I'd be happy to help you figure this out, but I
> don't think it's teechnically compliant with the spec.
> 
> seth
> 
>