- From: Francis Norton <francis@redrice.com>
- Date: Mon, 08 May 2000 23:55:10 +0100
- To: Michael Champion <Mike.Champion@SoftwareAG-USA.com>
- CC: www-dom-xpath@w3.org
Michael Champion wrote: > > ----- Original Message ----- > From: "Scott Boag/CAM/Lotus" <Scott_Boag@lotus.com> > To: <www-dom-xpath@w3.org> > Sent: Sunday, May 07, 2000 2:28 PM > Subject: [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. 1) may not be as simple as it sounds since we know that the Oracle interface includes namespace support and the Microsoft interface includes support for compiled queries - and this is only from a quick glance at the documentation. In other words an API that supports both feature sets will be a 2) rather than a 1) in any case. I vote that 2) is both necessary and sufficient. Afterthought - do we need to declare some kind of error handling if an XPath expression is called on an XML Fragment? Francis.
Received on Monday, 8 May 2000 18:56:06 UTC