Scott Boad wrote, > 1) Node already has 24 methods on it, which is quite enough. > 2) It requires that the XPath implementation be done *by* the > DOM implementation, instead of *on* the DOM > implementation. And a bunch of other arguments that I > have made in previous emails that I will not reiterate on. 1. As far as I understood form Mike, XPath support would be an option DOM module. So any new XPath methods would actually live on something like a NodeXPath interface rather than Node itself (cp. the other option modules in Level 2). In any case, the mere number of methods on an interface isn't a particularly interesting software design metric. 2. Allowing a DOM implementation to _optionally_ implement XPath itself opens up the possiblity for _significant_ optimizations over what can be achieved via the exisiting public API. (Mike, maybe you should chip on how that might pan out in the case of a DOM API to an XML database). Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)20 8817 4030 London, W6 0LJ, England msabin@cromwellmedia.com http://www.cromwellmedia.com/Received on Wednesday, 3 May 2000 13:22:05 GMT
This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:19:25 GMT