RE: [dom-xpath] Competing Proposals Proposal

>
> >
> > I would propose that we create three rough competing proposals for a DOM
> > XPath:
> >
> > 1) Ultra Minimal (e.g. Microsoft/Oracle selectNodes as they
> exist today).
> >
> > 2) Minimal but with separate interface+namespace context support.
> >
> > 3) Complete as makes sense (e.g. full context initialization, variable
> > support, maybe matching, maybe compiled queries, etc.)
> >
>
> OK, how about an informal poll.  a) Which of these are *necessary* for the
> first round of a DOM-compatible XPath API? b) Which are *sufficient*
(i.e.,
> we can stop when we get there)?
>
> I personally believe that 1 is necessary (backwards
> compatibility, make the simple cases simple) and 2 is sufficient.  3 would
be nice
> for the next iteration.  I could live with any consensus, however.
>

I don't think 1 can be done properly without addressing namespace context
support (see my last post). 1 & 2 are really a single option in my eyes.
Hence, I think 1 + ns context is all that's absolutely necessary for the
first iteration. And yes, 3 would be nice for the next iteration.

-aaron