RE: [dom-xpath] Competing Proposals Proposal

Scott:


     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'll presume a black box implementation from now on then. Thanks.


     > <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.
Thanks.


Re variables.
     > 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.

OK, if its agreed its a kludge, whats the loss to striking variables?
Do we have a usable solution without variables? (See also the last comment
below)



     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.

I'd rather it be explicit please. I'm guessing an implementation could
take the option of 'blowing up', given an invalid xpath expression.

     > '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.

I think that puts quite a different perspective on the document!
I'd still like to leave an option open to be explicit about the phrase
'expect an implementation to be conformant to the X spec (xpath, XQL or
xpointer'. I.e. to have the option to subset conformance to, say, a list
of spec para's (if its reasonable to do so).

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

Valid use case. Thanks. idea. *if* the variable could be resolved (as per
an entity) outside the black box, 'compiled' then passed into the black box
we have an answer. Feasability?



Regards, DaveP

Received on Thursday, 11 May 2000 22:21:00 UTC