|From:||Andrew Dunstan <andrew(at)dunslane(dot)net>|
|To:||Hannu Krosing <hannu(at)2ndQuadrant(dot)com>|
|Cc:||Simon Riggs <simon(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>|
|Subject:||Re: xpath processing brain dead|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Hannu Krosing wrote:
> Is it just that in you _can't_ use Xpath on fragments, and you _need_ to
> pass full documents to Xpath ?
> At least this is my reading of Xpath standard.
I think that's possibly overstating it., unless I have missed something
(W3 standards are sometimes not much more clear than the SQL standards ;-( )
For instance, there's this, that implies at least that the tree might
not be a document:
A "/" at the beginning of a path expression is an abbreviation for
the initial step fn:root(self::node()) treat as document-node()/
(however, if the "/" is the entire path expression, the trailing "/"
is omitted from the expansion.) The effect of this initial step is
to begin the path at the root node of the tree that contains the
context node. If the context item is not a node, a type error is
raised [err:XPTY0020]. At evaluation time, if the root node above
the context node is not a document node, a dynamic error is raised
The problem is that we certainly do have to provide a context node (the
standard is clear about that), and unless we want to convert a
non-document to a node-set as James suggested and then apply the xpath
expression to each node in the node-set, we have no way of sanely
specifying the context node.
|Next Message||Hannu Krosing||2009-03-02 14:12:37||Re: xpath processing brain dead|
|Previous Message||Peter Eisentraut||2009-03-02 13:25:34||Re: xpath processing brain dead|