W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1999

DOM LC suggestions (was Re: The DOM is not a model, it is a library!)

From: <keshlam@us.ibm.com>
Date: Thu, 7 Oct 1999 14:57:27 -0400
To: "DOM Mailing List" <www-dom@w3.org>
Message-ID: <85256803.0068228C.00@D51MTA03.pok.ibm.com>
Good thoughts, Steve; thanks!

A few thoughts and questions. Please don't take these as challenges; I'm trying
to make sure I understand the problems you're addressing, and sometimes the
easiest way to focus that is to ask "why wouldn't this work".

1) You requested the ability to produce an Iterator from a NodeList. I'm not
110% sure, but I _think_ you should be able to use an appropriate-filtered
NodeIterator to achieve the same results more directly. (Eg, a filter that tests
the node's name gives you something equivalent to getElementsByTagName.) If
you've got a counterexample which this doesn't handle, I'd be interested in
seeing it; that may mean we missed something in the Iterator's design.

2) One of the communities which requested ownerElement was XSL, which wants a
way to get the "parent" (in XSL terms) of any node. Since that node could be a
default Attr, we can't force ownerElement of defaults to null without breaking
their use case. Making that optional... Hm.

Sanity check: How painful would it be to have a lightweight proxy Attr, which
carries only the ownerElement field and consults a shared back-end object for
the rest of the Attr's behavior? It's not quite as cheap as sharing the whole
Attr, but it may be less expensive than duplicating the bigger object. If you
alter the value of an Attr you'd have to break that association to avoid
changing all instances, but that's doable.

3)  I too would have preferred that EntityReference be only a reference and that
folks consult the Entity to obtain its content, and now a TreeWalker or Iterator
could be made smart enough to follow that link for you. I'm not entirely opposed
to having that be a third recognized state alongside in-place expansion and the
current EntityRef-plus-subtree... though some folks are grumbling that two
options was already one too many. (Unfortunately they're still split on which
one they want!)

Note that you can actually achieve this result today, if (a) your DOM builds the
EntityReference's kids only when they're called for and (b) you can convince
users to adopt the appropriate coding style. In that case, the subtree would
only be replicated for users who don't follow your advice and insist on directly
asking for the EntRef's kids. Is that close enough, or do you really need the
new state to be made explicit?

4) People have run DOMs in palmtops and smartphones. It does require careful
coding. (I _wish_ Java had unions!) Yes, storage there will always be limited
compared to the desktop... as will bandwidth for download and CPU cycles, so
filtering/transcoding in the server may be worth considering as an alternative
to doing so on the palmtop.

This might be a legitimate niche for a DOM-compatable subset, rather than a full
DOM Level 1, especially since folks (currently) don't do much program
development on the palmtop itself.

5) Attaching side info to the tree: We have looked at that issue.  It seems to
be a reasonable idea, especially when described as "lightweight portable
subclassing". It gets a bit messier when you start thinking about what to do
when a node gets cloned, and we never decided whether this was Core or optional
(and if optional, whether part of an existing Feature or a Feature of its own).
We just didn't have a solid proposal ready in time for Level 2.

Joe Kesselman  / IBM Research
Received on Thursday, 7 October 1999 14:57:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:06 UTC