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

What function?  There are no standard functions that do take an untyped
DOM type.  And why DOM node?   And how would you specify in the standard
how to validate it?
Also - in Xpath 1.0 returned not are NOT the same as DOM nodes.  For
example DOM does not treat the element bearing an attribute as the
parent of the attribute.

It introduces a whole lot of very irrelevant and complicated machinery
for very little gain.   


-----Original Message-----
From: Prakash Yamuna [mailto:techpy@gmail.com] 
Sent: Friday, March 11, 2005 11:24 AM
To: Daniel Engovatov
Cc: Seth.Proctor@sun.com; Muhammad Masoom Alam;
Subject: Re: [xacml-users] AttributeSelector usage

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.

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
> a good thing as the upcoming XPath 2.0 data model is bit different -
> 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
> 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
> no reason to return an arbitrary type if it can not be an argument to
> function.  And if you introduce a new function that accepts a new type
> it is your responsibility to enhance the context handler to retrieve
> type checks those new types. This is abstracted away into the context,
> or your new function using an AttributeDesignator.
> Use Designators anyway. :)
> D;
> 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
> using)?
> Now wait a minute! :)
> My reading of the spec is that, indeed, AttributeSelectors must
> 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
> 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
> topic, since the spec has been remarkably incomplete or misleading in
> the past when it comes to the AttributeSelector element. This is part
> why I implemented the XPath handling of AttributeSelector in a
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]