W3C home > Mailing lists > Public > www-dom@w3.org > January to March 1998

Comments on the DOM (Core) Level 1

From: Alfie Kirkpatrick <akirkpatrick@ims-global.com>
Date: Tue, 3 Mar 1998 15:29:38 +0000
Message-Id: <TFSMIMWN@ims-global.com>>
To: www-dom@w3.org
I've been working to implement the DOM Core spec.
as MSVC++ ATL (Active Template Library) COM objects
and have a few comments on the draft.

Most of my comments relate to the creation of a DOM
document from scratch within the parser module. My
objects are implemented in one module and the parser
(using the native SP API) in another. Because of this,
the parser only has access to the objects through their
strict COM interfaces, so I'm hitting problems with your
second design goal: "sufficient to construct an entirely
new document...".

Anyway, here are my comments:

 - I needed to add a setTagName method to the Element
  object. This also highlights an inconsistency between
  Element and Text. The Text object has a 'data' property.
  Why isn't Element the same? Eg. 'tag' or 'gi' property.
  Perhaps it is because the tag may be held as an atom, so
  might not be a strict property? Is the idea that the
  DOMFactory handles the tag names and sets up the Element
  internally (sorry, I just thought of that)?

 - I needed to add a setParentNode method to the Node object.
  Otherwise, how can insertBefore, replaceChild, removeChild
  modify the child element to keep the structure consistent?
  This brought up a number of related issues. For example,
  how should insertBefore behave if the child already has
  a parent? Should it quietly call removeChild on the original
  parent or should it give an error (NotMyChildException)?

I also have some platform/implementation specific issues which
may or may not be of interest:

 - It would be useful to have an appendData method on the
  Text object. At the moment, the parser generates numerous
  data events for a single run of text content. I want to
  merge these together where possible into a single Text node.
  However, because of the way COM works, it will be highly
  inefficient to get the data, append and then write it back
  to the object. This will result in a get (alloc, copy),
  append (realloc, concat), put (realloc, copy). This could
  be reduced to an append (realloc, concat). I can imagine
  this would also be useful to other client applications.

 - In order to implement a child list, a Node has an
  EditableNodeList member object. This is so it can pass
  out a dynamic NodeList as required by the spec (under
  the description of getChildren). However, in COM, any
  client could just do a QueryInterface to get to the
  EditableNodeList object and then hack around with the
  children. In fact, in VB the distinction wouldn't ever
  be there since any calls to methods on an object always
  result in a QueryInterface.

 - I'm not sure if it is possible to provide custom exceptions
  within COM objects. Error handling is usually done by passing
  a non-zero HRESULT from the "method". Return values are handled
  using special MIDL [out,retval] parameters. Any thoughts?

Thanks for listening -- I've been having lots of fun wrestling
with MSVC/COM over the last week, NOT!

Alfie Kirkpatrick
Received on Tuesday, 3 March 1998 10:39:01 UTC

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