RE: [dom-xpath] Competing Proposals Proposal

dave.pawson@virgin.net wrote:
> Hence I asked which way were you facing when
> you made this statement? from within the black box looking out, or
> from the outside looking in?

From the outside looking in, I think.

> I don't understand mutated. The *only* interface I have used didn't
> permit me to iterate over the nodelist more than once. I found this
> restrictive and didn't want it repeated.

OK.  Yes, I agree.

> <q>It should provide an interface for XSLT Match Patterns. Though they
are
> XSLT and not XPath, they are very useful.</q>
> Its a should not a shall. Are we all OK to include XSLT items in what is
> supposed to be an xpath focus. Without going to xslt rec I'm unable to
> comprehend the implications of this. Hence the -1. Perhaps if someone
> explored the ramifications of stating an intent to implement paras
> a b c d of xslt then I could understand it. Hence the call to be
explicit.

Yep, I hear, and understand that match patterns will be likely to be
stricken.  But it's an interesting thing to consider.  I will try to work
up some explicit detail on this.

>  I guess I'm thinking
> about why variables (constants?) were added to xpath xslt. I can't find
> a direct use for them in a (for example) java implementation which
already
> has variables. whats the implication of ignoring xpath variables 'across'
> the interface?

They're certainly needed for XSLT.  For XPath, they are needed anytime you
want to paramaterize the expression.  Yes, you could do selectNode
("path/to/node[@attr="+java-variable+"]"), but, besides being rather ugly,
that doesn't really work with the Expression object, since it's
pre-compiled.

> can I do 'path/to/node[@attr=java-variable]' 'somehow'
> without xpath ish type variables? Beyond me, sorry.

XPath syntax-wise, you would have to do 'path/to/node[@attr
=$java-variable]'.  From the standpoint of the expression implementation, I
don't think there's any way for the expression implementation to access the
calling program's stack variables directly.

>      > <q>without having to re-parse the expression</q> No prior mention
of
>      > the expressions needing to be parsed.
>
>      Huh?  Expressions always need to be parsed!
>
> Not the point. Within the document there is no requirement statement
> that xpath expressions need parsing. Hence if that is not a requirement
> then how can there be a requirement to re-parse? Nit picking maybe.
> But the document should stand as 'complete'. Suggest add a requirement
> to parse xpath paths.

Parsing is implicit.  It has to be done at some point.  I don't think a
requirement of parsing makes sense... that's part of the implementation,
not the API.  But it's a performance issue for the API.

> 'Straying' perhaps from xpath? A context includes a define suite of
> functions if I remember rightly. Will this be supported or not?

As the document stands, it is not making a requirement as to conformance.
If you're passing in an "XPath" expression, I would expect the
implementation to be conformant to the XPath spec, and if you're passing in
an "XQL" expression, I would expect the expression to be conformant to XQL.
In other words, I don't think the API itself needs to make statements about
conformance of the given expression implementation.  It only needs to make
sure the API is rich enough to support the needs of the expression
implementation.

> As I note above, I'm uncomfortable with variables of this type in
> a variable rich environment. What functionality is lost if variables
> are? Or perhaps we could 'parse' them out (i.e. have the parser replace
> variables with values prior to passing them 'across' the api? I ask
> again why, looking to my note above about why they were introduced into
> xpath). If I'm still not clear after this one I'm prepared to drop my
> objections. Variables seem like a kludge looking for elegance.
> (I'm beginning to think I'm very unclear here ;-)

As per my comment above.  For the Expression object, you can't have the
parser parse them out, since you may want to use a single expression object
and pass many different variables to it.  Use case: I'm a servlet, and I
get a servlet parameter that specifies that I want only name nodes with the
value of "Dave Pason".  So I create an Expression with the input of
"people/names[.=$name-arg]".  This expression can be compiled once, but
then used millions of times over the course of the servlet's life.

I'll add the above issues as open issues in the next edit of the proposal.

-scott

Received on Thursday, 11 May 2000 15:10:15 UTC