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