- From: Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
- Date: Thu, 4 May 2000 13:21:59 -0400
- To: www-dom-xpath@w3.org
Jonathan Marsh <jmarsh@microsoft.com> wrote: > Personally, I feel DOM is already bloated almost > beyond useability Thank you for that. This has been the message I've received when talking to both users and implementors. > while simultaneously missing vital functionality. I > include XPath support in the latter category. The question is, is it "core" to what the DOM is? Maybe so. You could make the argument that a database interface (JDBC, for instance) would be pretty silly without the Statement object (for example). (As a matter of fact, one could argue that JDBC/ODBC is a pretty good comparitive model for this task). On the other hand, XPath isn't yet a full query language, so there is the danger of jumping the gun. > I observe that one person's feature is another person's bloat I notice that MS has transformNode and transformNodeToObject as core methods on your DOM. Is that the next core feature to be introduced? You could probably make close to the same argument I made above about transformations. Are selections and transformations core to a "Document Object Model", or are they simply particular tools that operate on the DOM? I sure the hell hope that someone will *not* introduce transformNode and transformNodeToObject as the next "core" feature needed. > - minimal, convenience-oriented (e.g. Microsoft/Oracle selectNodes) Well, I quote the familiar from Einstein:: "As simple as possible, but not simpler". This isn't much help, but I had to say it. Microsoft/Oracle implements directly on the Node interface, instead of having a separate Expression/XPath interface. If you do minimal, convenience-oriented, I'm not sure you can plop this on a non-Node interface, which makes it harder to make it an optional feature, and it would have to wait 'till DOM3. If we could do a minimal, convenience-oriented method as another interface, which could eventually be derived to make fuller featured, I could probably live with the minimal approach. > - complete (e.g. full context initialization, matching, etc.) When you're doing design for general use, you have to consider everyone's needs, which is one of the reasons the DOM is as it is today. Even a minimal design is hard to do without considering the details of a complete design. > - performant (complete + compiled queries, streaming support, etc.) Ditto to what I said about a complete design. I would either choose: #1 with limited syntax support (i.e. selectNodes(pattern), and selectSingleNode(pattern), LocationPaths only, no namespace, variable, or extensions support), in a separate interface, with some idea of how we would scale up to a full featured interface. #1+#2+#3, designed so you can do simple things simply. If you pushed me hard, I guess I would lean towards #1, published as a note within the next couple of months, and wait for #2 and #3 'till the XML Query work is a little further along. Though, without namespace support, I question how useful it would be. > Deciding early on what > the goal is will smooth the entire process. Big agreement on this point. -scott
Received on Thursday, 4 May 2000 13:21:55 UTC