Hi Tinny,
 
How are you going to fix the IDOM memory leak?  How are you going to support implementations with different memory models?  Why are you presenting the IDOM as an effective alternative, one worthy of gambling future Xerces development on without resolving these issues?
 
As far as standardizing is concerned, I don't see why the DOM interface can't be standardized, doing so does not dictate any particular implementation.  What is the difference between standardizing the DOM handles (noting that they can be implemented any way desired, i.e. by desired by deriving from the IDOM abstract base classes using a handle/body pattern) and standardizing the IDOM abstract base classes noting they can be implemented any way desired (i.e. by deriving from the IDOM abstract base classes).
 
Lenny
-----Original Message-----
From: Tinny Ng [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 29, 2002 11:16 AM
To: [EMAIL PROTECTED]
Subject: Re: Call for Vote: which one to be the Xerces-C++ public supported W3C DOM interface

> Vote Question

> ==>  Which INTERFACE should be the Xerces-C++ public supported W3C DOM Interface, DOM or IDOM? <===

My vote:  IDOM

- I prefer IDOM over DOM. The smart pointer does not buy me much compared to an official Apache DOM C++ Binding.  Agree with Joseph, I think abstract base classes is more standard-like and is the right way to go.

- With DOM-IDOM integration, although IDOM will be hidden, it is still a dual interface maintenace. From Xerces-C++ active committer perspective, I would prefer focus on IDOM only.   The old DOM interface can be kept for compatibility, but we don't want to upgrade it with those DOM Level 3 interface, and dual maintain both DOMParser and IDOMParser.

Reply via email to