RE: [dom-xpath] Competing Proposals Proposal

dave.pawson@virgin.net wrote:
> OK, if its agreed its a kludge, whats the loss to striking variables?

I don't agree that the variable stack is a kludge.

> Do we have a usable solution without variables? (See also the last
comment
below)

Not in the "complete" (i.e. "3)") proposal.

BTW, people should feel free to take my document and hack it up into the 1)
and 2) proposals, or even a competing 3) proposal.  The best way towards
good design is to have lots of options and ideas on the table.

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

Certainly.  Notice the ExpressionFactory.create throwing the
ParseException.  Probably the Inquirer methods should also throw this
exception.

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

OK.

> *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?

Not sure how you would compile a variable.

To be clear, here's how it would look:

ExpressionFactory efactory = ExpressionFactory.newInstance("Xpath");
Expression expr = efactory.create("foo/baz[greeting=$foo]",
myPrefixResolver);
myXEnvironment.pushVariable("foo", "hello");
XObject val1 = expr.evaluate(myNode, myXEnvironment);
myXEnvironment.popVariable();
myXEnvironment.pushVariable("foo", "goodby");
XObject val2 = expr.evaluate(myNode, myXEnvironment);
myXEnvironment.popVariable();

-scott

Received on Friday, 12 May 2000 00:16:19 UTC