Re: Is minimalism a goal?

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