You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Lenny Hoffman <le...@earthlink.net> on 2002/02/19 23:36:04 UTC
RE: Proposal: C++ Language Binding for DOM Level 2 - in termofIDOM
Re: Proposal: C++ Language Binding for DOM Level 2 - in term ofIDOMHi All,
I changes I proposed and submitted (IDOM/DOM integration) should be
considered here. Making the current IDOM and its interface standard will
fix its memory model, which makes it hard to have alternative
implementations. Having the flexibility to plug in different
implementations while maintaining a consistent external interface not only
helps folks like me who are creating DOM adapters to existing OO interfaces,
but also make it easier for the Xerces group to evolve the implementation as
it sees fit for performance without having to maintain parallel interfaces
like it has in the past (DOM and IDOM). In general, I believe it unwise to
standardize a memory model.
Here is the summary I provided for Bugzilla #5967:
The DOM interfaces have lightweight smart pointers to referenced counted
implementation objects, while the IDOM interfaces eliminate the smart
pointer
and the reference counting. The proposal is simply to add lightweight smart
pointers to the IDOM implementation. Reference counting is still
eliminated,
but the smart pointers facilitate an interface that retains familiarity with
the Java version of xerces and allows for different back ends
(implementations)
to be plugged in. One back end would be the IDOM itself, while others could
be
application specific adapters (for those that want to provide a DOM API to
their application), database adapters, etc.
If the IDOM is standardized as is, I loose the ability to have a standard
C++ DOM interface to my product. I simply can't keep all that is behind the
DOM interface in memory at once, and I need the indirection provided by DOM
instances to keep track of what is in use and what can be discarded. To
facilitate this I added "addRef" and "removeRef" methods to IDOM_Node that
my implementation can use, but are simply ignored by the current Xerces IDOM
implementation.
If the IDOM/DOM integration is accepted, then no renaming has to occur, and
the "I" in "IDOM" can be thought to represent Implementation, for that is
what the role of all IDOM classes have become after the change. The primary
interface remains through the DOM classes and and offers the greatest degree
of backwards compatibility. Note that the way I made the changes that
current users of IDOM are unaffected, and if the DOM interface is
standardized than all that would happen to them is that they are not using
the standard interface, which they is their current situation anyway.
Meanwhile, they can adopt the DOM interfaces at their leisure without any
noticeable performance degradation.
Regards,
Lenny
-----Original Message-----
From: James Berry [mailto:jberry@criticalpath.com]
Sent: Tuesday, February 19, 2002 3:54 PM
To: Xerces C Dev
Subject: Re: Proposal: C++ Language Binding for DOM Level 2 - in
termofIDOM
Ive heard at least two concerns/proposals regarding what needs to be
addressed in this proposed binding:
(1) Normalize names per Tinny below: IDOM_Document --> DOMDocument,
etc.
(2) Alter IDOM memory/ownership model such that memory belongs to
the document rather than to the parser. Or provide a means of disassociating
a document from the parser so that when the parser goes away it will not
destroy the document. I would advocate that this should be done implicitly
on successful completion of a parse: at such point the document becomes
stand-alone with no further ties to the parser; if the parse fails, there
s no document and so the issue is moot.
(3) Grumblings about the Corba-ish roots of the Xerces DOM and
presumably IDOM. Are there any concrete proposal for changes there?
It would be nice to get further discussion on these issues, and or any
additional that need to be raised. Once that is complete, perhaps it will be
time for a vote on carrying this forward...?
-jdb
On 2/19/02 1:38 PM, "Tinny Ng" <tn...@ca.ibm.com> wrote:
I also heard other similar complaints about the name "IDOM".
I've no idea why it was named "IDOM", my binding proposal just inherits
whatever already implemented there .....
If we are going to give it a new name, then it means all existing IDOM
files (e.g. IDOM_Node.hpp) and IDOM classes (e.g. class IDOM_Node) will be
renamed accordingly. Then all existing IDOM users need to do such global
rename migration after the binding proposal is approved by the mailing list.
Since the IDOM was still in "experimental" state in Xerces-C++ 1.6.0 and
thus considerable API changes should be expected, may be such "global rename
migration" is acceptable to IDOM users??
If most existing IDOM users vote for the rename, then we can pick a more
reasonable name. How about prefix it with "DOM" (not "DOM_" as in the old
DOM)? For example
DOMDocument
DOMElement
DOMNode
DOMAttribute
DOMRange
...
etc.
??
Tinny
----- Original Message -----
From: James Berry <ma...@criticalpath.com>
To: Xerces C Dev <ma...@xml.apache.org>
Sent: Sunday, February 17, 2002 1:33 PM
Subject: Re: Proposal: C++ Language Binding for DOM Level 2 - in term
ofIDOM
Hi Tinny,
The purest in me is somewhat concerned with regard to whether the name
IDOM is appropriate for something that might be on the way to becoming a
standard DOM binding for C++. (I guess, also, that I dont know what the I
in IDOM stands for... ;)
Is the existing DOM interface recognized as an official binding in
any way for C++?
If the Xerces DOM interface goes away, or becomes deprecated, which
it seems destined to, it would seem logical for the IDOM interface to
become named DOM instead, rather than the randomly named (???) IDOM.
Maybe my concerns will be cleared up if someone convinces me that
theres a valid naming convention behind IDOM. Is that interface?
interim? investigatory? improved? What about CppDOM, StdDOM.
Comments?
-jdb
On 2/15/02 8:31 AM, "Tinny Ng" <tn...@ca.ibm.com> wrote:
Hi,
W3C DOM Recommendation has only defined JAVA and ECMAScript language
bindings. For all other languages, W3C has links to binding owners' web
sites in http://www.w3.org/DOM/Bindings.
In order to populate Xerces-C++ IDOM as a formal C++ language
binding to more open source users, I would like to post the attached
document to Apache Xerces-C++ web site, and then send the URL to
http://www.w3.org/DOM/Bindings.
The proposed document is almost the same as our existing IDOM
interfaces, with the following exceptions:
1. Introduce the type "IDOMSize_t" which is an
implementation-dependent unsigned integral type. And use it in interfaces
like:
IDOM_Node* IDOM_NodeList::item(IDOMSize_t index) = 0;
IDOMSize_t IDOM_NodeList::getLength() = 0;
2. Added abstract classes IDOM_DocumentTraversal and
IDOM_DocumentRange, and derived IDOM_Document from these two abstract
classes in addition to IDOM_Node in the implementation. These two
interfaces were not there in existing IDOM and this is to fix such
deviation.
Please review and let me know any comment. I hope to have this in
place together with Xerces-C++ 1.7 announcement. Thanks!
Regards,
Tinny Ng
XML Parsers Development
IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
------------------------------------------------------------------------
C++ Language Binding for DOM Level 2
This document contains the complete C++ Language binding for the
Level 2 Document Object Model Core, and for the Level 2 Document Object
Model Traversal and Range. The definitions are divided into Core <#A:
Document Object Mode: Core> , Traversal <#B: Document Object Model:
Traversal> , and Range <#C: Document Object Model: Range> .
The headers are also available in Apache Xerces-C++ IDOM
distribution: http://cvs.apache.org/viewcvs.cgi/xml-xerces/c/src/idom/
<http://cvs.apache.org/viewcvs.cgi/xml-xerces/c/src/idom>
Note:
1.. Constructor and Destructors are implementation specific
2.. String is represented by "XMLCh*" which is a pointerto
unsigned 16 bit type holding utf-16 values, null terminated.
1.. typedef unsigned int XMLCh
3.. IDOMSize_t is an implementation-dependent unsignedintegral
type
1.. typedef unsigned long IDOMSize_t
------------------------------------------------------------------------
A: Document Object Mode: Core <#C++ Language Binding for DOM Level
2>
IDOM_DOMException.hpp:
class IDOM_DOMException
{
public:
// ExceptionCode
enum ExceptionCode {
INDEX_SIZE_ERR = 1,
DOMSTRING_SIZE_ERR = 2,
HIERARCHY_REQUEST_ERR = 3,
WRONG_DOCUMENT_ERR = 4,
INVALID_CHARACTER_ERR = 5,
NO_DATA_ALLOWED_ERR = 6,
NO_MODIFICATION_ALLOWED_ERR = 7,
NOT_FOUND_ERR = 8,
NOT_SUPPORTED_ERR = 9,
INUSE_ATTRIBUTE_ERR = 10,
INVALID_STATE_ERR = 11,
SYNTAX_ERR = 12,
INVALID_MODIFICATION_ERR = 13,
NAMESPACE_ERR = 14,
INVALID_ACCESS_ERR = 15
};
const XMLCh* msg;
ExceptionCode code;
};
IDOM_DOMImplementation.hpp:
class IDOM_DOMImplementation
{
public:
virtual bool hasFeature(const XMLCh* feature,
const XMLCh* version) = 0;
virtual IDOM_DocumentType* createDocumentType(const XMLCh*
qualifiedName,
const XMLCh*
publicId,
const XMLCh*
systemId) = 0;
virtual IDOM_Document* createDocument(const XMLCh*
namespaceURI,
const XMLCh*
qualifiedName,
IDOM_DocumentType*
doctype) = 0;
};
IDOM_DocumentFragment.hpp:
class IDOM_DocumentFragment : IDOM_Node
{
};
IDOM_Document.hpp:
class IDOM_Document : IDOM_Node
{
public:
virtual IDOM_DocumentType* getDoctype() const = 0;
virtual IDOM_DOMImplementation* getImplementation() const = 0;
virtual IDOM_Element* getDocumentElement() const = 0;
virtual IDOM_Element* createElement(const XMLCh* tagName)
= 0;
virtual IDOM_DocumentFragment* createDocumentFragment() = 0;
virtual IDOM_Text* createTextNode(const XMLCh* data) =
0;
virtual IDOM_Comment* createComment(const XMLCh* data) =
0;
virtual IDOM_CDATASection* createCDATASection(const XMLCh*
data) = 0;
virtual IDOM_ProcessingInstruction*
createProcessingInstruction(const XMLCh* target,
const XMLCh* data) = 0;
virtual IDOM_Attr* createAttribute(const XMLCh* name)
= 0;
virtual IDOM_EntityReference* createEntityReference(const XMLCh*
name) = 0;
virtual IDOM_NodeList* getElementsByTagName(const XMLCh*
tagname) const = 0;
virtual IDOM_Node* importNode(IDOM_Node* importedNode,
bool deep) = 0;
virtual IDOM_Element* createElementNS(const XMLCh*
namespaceURI,
const XMLCh*
qualifiedName) = 0;
virtual IDOM_Attr* createAttributeNS(const XMLCh*
namespaceURI,
const XMLCh*
qualifiedName) = 0;
virtual IDOM_NodeList* getElementsByTagNameNS(const XMLCh*
namespaceURI,
const XMLCh*
localName) const = 0;
virtual IDOM_Element* getElementById(const XMLCh*
elementId) const = 0;
};
IDOM_Node.hpp:
class IDOM_Node
{
public:
// NodeType
enum NodeType {
ELEMENT_NODE = 1,
ATTRIBUTE_NODE = 2,
TEXT_NODE = 3,
CDATA_SECTION_NODE = 4,
ENTITY_REFERENCE_NODE = 5,
ENTITY_NODE = 6,
PROCESSING_INSTRUCTION_NODE = 7,
COMMENT_NODE = 8,
DOCUMENT_NODE = 9,
DOCUMENT_TYPE_NODE = 10,
DOCUMENT_FRAGMENT_NODE = 11,
NOTATION_NODE = 12
};
virtual const XMLCh* getNodeName() const = 0;
virtual const XMLCh* getNodeValue() const = 0;
virtual void setNodeValue(const XMLCh* nodeValue) =
0;
virtual short getNodeType() const = 0;
virtual IDOM_Node* getParentNode() const = 0;
virtual IDOM_NodeList* getChildNodes() const = 0;
virtual IDOM_Node* getFirstChild() const = 0;
virtual IDOM_Node* getLastChild() const = 0;
virtual IDOM_Node* getPreviousSibling() const = 0;
virtual IDOM_Node* getNextSibling() const = 0;
virtual IDOM_NamedNodeMap* getAttributes() const = 0;
virtual IDOM_Document* getOwnerDocument() const = 0;
virtual IDOM_Node* insertBefore(IDOM_Node* newChild,
IDOM_Node* refChild) =
0;
virtual IDOM_Node* replaceChild(IDOM_Node* newChild,
IDOM_Node* oldChild) =
0;
virtual IDOM_Node* removeChild(IDOM_Node* oldChild) = 0;
virtual IDOM_Node* appendChild(IDOM_Node* newChild) = 0;
virtual bool hasChildNodes() const = 0;
virtual IDOM_Node* cloneNode(bool deep) const = 0;
virtual void normalize() = 0;
virtual bool isSupported(const XMLCh* feature,
const XMLCh* version)
const = 0;
virtual const XMLCh* getNamespaceURI() const = 0;
virtual const XMLCh* getPrefix() const = 0;
virtual void setPrefix(const XMLCh* prefix) = 0;
virtual const XMLCh* getLocalName() const = 0;
virtual bool hasAttributes() const = 0;
};
IDOM_NodeList.hpp:
class IDOM_NodeList
{
public:
virtual IDOM_Node* item(IDOMSize_t index) = 0;
virtual IDOMSize_t getLength() = 0;
};
IDOM_NamedNodeMap.hpp:
class IDOM_NamedNodeMap
{
public:
virtual IDOM_Node* getNamedItem(const XMLCh* name) const =
0;
virtual IDOM_Node* setNamedItem(IDOM_Node* arg) = 0;
virtual IDOM_Node* removeNamedItem(const XMLCh* name) = 0;
virtual IDOM_Node* item(IDOMSize_t index) const = 0;
virtual IDOMSize_t getLength() const = 0;
virtual IDOM_Node* getNamedItemNS(const XMLCh* namespaceURI,
const XMLCh* localName)
const = 0;
virtual IDOM_Node* setNamedItemNS(IDOM_Node* arg) = 0;
virtual IDOM_Node* removeNamedItemNS(const XMLCh*
namespaceURI,
const XMLCh* localName)
= 0;
};
IDOM_CharacterData.hpp:
class IDOM_CharacterData : IDOM_Node
{
public:
virtual const XMLCh* getData() const = 0;
virtual void setData(const XMLCh* data) = 0;
virtual IDOMSize_t getLength() const = 0;
virtual const XMLCh* substringData(IDOMSize_t offset,
IDOMSize_t count) const = 0;
virtual void appendData(const XMLCh* arg) = 0;
virtual void insertData(IDOMSize_t offset,
const XMLCh* arg) = 0;
virtual void deleteData(IDOMSize_t offset,
IDOMSize_t count) = 0;
virtual void replaceData(IDOMSize_t offset,
IDOMSize_t count,
const XMLCh* arg) = 0;
};
IDOM_Attr.hpp:
class IDOM_Attr : IDOM_Node
{
public:
virtual const XMLCh* getName() const = 0;
virtual bool getSpecified() const = 0;
virtual const XMLCh* getValue() const = 0;
virtual void setValue(const XMLCh* value) = 0;
virtual IDOM_Element* getOwnerElement() const = 0;
};
IDOM_Element.hpp:
class IDOM_Element: IDOM_Node
{
public:
virtual const XMLCh* getTagName() const = 0;
virtual const XMLCh* getAttribute(const XMLCh* name) const = 0;
virtual void setAttribute(const XMLCh* name,
const XMLCh* value) = 0;
virtual void removeAttribute(const XMLCh* name) = 0;
virtual IDOM_Attr* getAttributeNode(const XMLCh* name) const =
0;
virtual IDOM_Attr* setAttributeNode(IDOM_Attr* newAttr) = 0;
virtual IDOM_Attr* removeAttributeNode(IDOM_Attr* oldAttr) = 0;
virtual IDOM_NodeList* getElementsByTagName(const XMLCh* name)
const = 0;
virtual const XMLCh* getAttributeNS(const XMLCh* namespaceURI,
const XMLCh* localName) const
= 0;
virtual void setAttributeNS(const XMLCh* namespaceURI,
const XMLCh* qualifiedName,
const XMLCh* value) = 0;
virtual void removeAttributeNS(const XMLCh* namespaceURI,
const XMLCh* localName) =
0;
virtual IDOM_Attr* getAttributeNodeNS(const XMLCh*
namespaceURI,
const XMLCh* localName)
const = 0;
virtual IDOM_Attr* setAttributeNodeNS(IDOM_Attr* newAttr) = 0;
virtual IDOM_NodeList* getElementsByTagNameNS(const XMLCh*
namespaceURI,
const XMLCh*
localName) const =0;
virtual bool hasAttribute(const XMLCh* name) const = 0;
virtual bool hasAttributeNS(const XMLCh* namespaceURI,
const XMLCh* localName) const
= 0;
};
IDOM_Text.hpp:
class IDOM_Text: IDOM_CharacterData
{
public:
virtual IDOM_Text* splitText(IDOMSize_t offset) = 0;
};
IDOM_Comment.hpp:
class IDOM_Comment: IDOM_CharacterData
{
};
IDOM_CDATASection.hpp:
class IDOM_CDATASection: IDOM_Text
{
};
IDOM_DocumentType.hpp:
class IDOM_DocumentType: IDOM_Node
{
public:
virtual const XMLCh* getName() const = 0;
virtual IDOM_NamedNodeMap* getEntities() const = 0;
virtual IDOM_NamedNodeMap* getNotations() const = 0;
virtual const XMLCh* getPublicId() const = 0;
virtual const XMLCh* getSystemId() const = 0;
virtual const XMLCh* getInternalSubset() const = 0;
};
IDOM_Notation.hpp:
class IDOM_Notation: IDOM_Node
{
public:
virtual const XMLCh* getPublicId() const = 0;
virtual const XMLCh* getSystemId() const = 0;
};
IDOM_Entity.hpp:
class IDOM_Entity: IDOM_Node
{
public:
virtual const XMLCh* getPublicId() const = 0;
virtual const XMLCh* getSystemId() const = 0;
virtual const XMLCh* getNotationName() const = 0;
};
IDOM_EntityReference.hpp:
class IDOM_EntityReference: IDOM_Node
{
};
IDOM_ProcessingInstruction.hpp:
class IDOM_ProcessingInstruction: IDOM_Node
{
public:
virtual const XMLCh* getTarget() const = 0;
virtual const XMLCh* getData() const = 0;
virtual void setData(const XMLCh* data) = 0;
};
------------------------------------------------------------------------
B: Document Object Model: Traversal <#C++ Language Binding for DOM
Level 2>
IDOM_NodeIterator.hpp:
class IDOM_NodeIterator
{
public:
virtual IDOM_Node* getRoot() const = 0;
virtual unsigned long getWhatToShow() const = 0;
virtual IDOM_NodeFilter* getFilter() const = 0;
virtual bool getExpandEntityReferences() const = 0;
virtual IDOM_Node* nextNode() = 0;
virtual IDOM_Node* previousNode() = 0;
virtual void detach() = 0;
};
IDOM_NodeFilter.hpp:
class IDOM_NodeFilter
{
public:
// FilterAction
enum FilterAction {
FILTER_ACCEPT = 1,
FILTER_REJECT = 2,
FILTER_SKIP = 3
};
// ShowType
enum ShowType {
SHOW_ALL = 0x0000FFFF,
SHOW_ELEMENT = 0x00000001,
SHOW_ATTRIBUTE = 0x00000002,
SHOW_TEXT = 0x00000004,
SHOW_CDATA_SECTION = 0x00000008,
SHOW_ENTITY_REFERENCE = 0x00000010,
SHOW_ENTITY = 0x00000020,
SHOW_PROCESSING_INSTRUCTION = 0x00000040,
SHOW_COMMENT = 0x00000080,
SHOW_DOCUMENT = 0x00000100,
SHOW_DOCUMENT_TYPE = 0x00000200,
SHOW_DOCUMENT_FRAGMENT = 0x00000400,
SHOW_NOTATION = 0x00000800
};
virtual short acceptNode (const IDOM_Node* node) const = 0;
};
IDOM_TreeWalker.hpp:
class IDOM_TreeWalker
{
public:
virtual IDOM_Node* getRoot() const = 0;
virtual unsigned long getWhatToShow()const = 0;
virtual IDOM_NodeFilter* getFilter()const = 0;
virtual bool getExpandEntityReferences()const = 0;
virtual IDOM_Node* getCurrentNode()const = 0;
virtual void setCurrentNode(IDOM_Node* currentNode)=
0;
virtual IDOM_Node* parentNode()= 0;
virtual IDOM_Node* firstChild()= 0;
virtual IDOM_Node* lastChild()= 0;
virtual IDOM_Node* previousSibling()= 0;
virtual IDOM_Node* nextSibling()= 0;
virtual IDOM_Node* previousNode()= 0;
virtual IDOM_Node* nextNode()= 0;
};
IDOM_DocumentTraversal.hpp:
// This interface can be obtained from the object implementing the
// Document interface using binding-specific casting methods.
class IDOM_DocumentTraversal
{
public:
virtual IDOM_NodeIterator* createNodeIterator(IDOM_Node* root,
unsigned long
whatToShow,
IDOM_NodeFilter*
filter,
bool
entityReferenceExpansion) = 0;
virtual IDOM_TreeWalker* createTreeWalker(IDOM_Node* root,
unsigned long
whatToShow,
IDOM_NodeFilter*
filter,
bool
entityReferenceExpansion) = 0;
};;
------------------------------------------------------------------------
C: Document Object Model: Range <#C++ Language Binding for DOM Level
2>
IDOM_RangeException.hpp:
class IDOM_RangeException : IDOM_DOMException
{
public:
// IDOM_RangeExceptionCode
enum IDOM_RangeExceptionCode {
BAD_BOUNDARYPOINTS_ERR = 1,
INVALID_NODE_TYPE_ERR = 2
};
IDOM_RangeExceptionCode code;
};
IDOM_Range.hpp:
class IDOM_Range
{
public:
// CompareHow
enum CompareHow {
START_TO_START = 0,
START_TO_END = 1,
END_TO_END = 2,
END_TO_START = 3
};
virtual IDOM_Node* getStartContainer() const = 0;
virtual IDOMSize_t getStartOffset() const = 0;
virtual IDOM_Node* getEndContainer() const = 0;
virtual IDOMSize_t getEndOffset() const = 0;
virtual bool getCollapsed() const = 0;
virtual const IDOM_Node* getCommonAncestorContainer() const = 0;
virtual void setStart(const IDOM_Node* parent,
IDOMSize_t offset) = 0;
virtual void setEnd(const IDOM_Node* parent,
IDOMSize_t offset) = 0;
virtual void setStartBefore(const IDOM_Node* refNode) =
0;
virtual void setStartAfter(const IDOM_Node* refNode) =
0;
virtual void setEndBefore(const IDOM_Node* refNode) =
0;
virtual void setEndAfter(const IDOM_Node* refNode) = 0;
virtual void collapse(bool toStart) = 0;
virtual void selectNode(const IDOM_Node* node) = 0;
virtual void selectNodeContents(const IDOM_Node* node)
= 0;
virtual short compareBoundaryPoints(CompareHow how,
const IDOM_Range*
range) const = 0;
virtual void deleteContents() = 0;
virtual IDOM_DocumentFragment* extractContents() = 0;
virtual IDOM_DocumentFragment* cloneContents() const = 0;
virtual void insertNode(IDOM_Node* node) = 0;
virtual void surroundContents(IDOM_Node* node) = 0;
virtual IDOM_Range* cloneRange() const = 0;
virtual const XMLCh* toString() const = 0;
virtual void detach() = 0;
};
IDOM_DocumentRange.hpp:
// This interface can be obtained from the object implementing the
// Document interface using binding-specific casting methods.
class IDOM_DocumentRange
{
public:
virtual IDOM_Range* createRange() = 0;
};
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------------------------------------------------
-
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Proposal: C++ Language Binding for DOM Level 2 - in termofIDOM
Posted by Lenny Hoffman <le...@earthlink.net>.
Hi Jason,
I downloaded and ran the tests, but even on my 512MB machine the IThreadTest
executed for 120 seconds against "simple.xml" (as setup in the perl scrip)
against CVS build (2002-02-06) runs my machine out of memory and then
crashes as a result. The same thing happens when I run it against the
DOM/IDOM integrated version, of course.
I'm not sure what is going on, but will investigate to try and figure it
out. If anyone knows of the recent history of these tests that could help;
for instance, has anyone been able to run them successfully recently?
Regards,
Lenny
-----Original Message-----
From: Jason E. Stewart [mailto:jason@openinformatics.com]
Sent: Tuesday, February 19, 2002 6:34 PM
To: xerces-c-dev@xml.apache.org; lenny.hoffman@objectivity.com
Subject: Re: Proposal: C++ Language Binding for DOM Level 2 - in
termofIDOM
"Lenny Hoffman" <le...@earthlink.net> writes:
> Re: Proposal: C++ Language Binding for DOM Level 2 - in termofIDOMHi
James,
>
> I went ahead and performed and submitted the refactoring. The results are
> (as posted earlier):
>
> IDOMCount and DOMCount now take the same amount of time. Not a
> surprise, as the IDOM is now behind DOM, which only adds a
> lightweight smart pointer overhead. If there is a better
> performance test for comparing, please let me know.
Check out the performance tests that AndyH did:
http://www.apache.org/~andyh/xmlbench/
I would run these on the standard 1.6 DOM and IDOM (before your mods)
and then IDOM and DOM after your mods.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Proposal: C++ Language Binding for DOM Level 2 - in termofIDOM
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Lenny Hoffman" <le...@earthlink.net> writes:
> Re: Proposal: C++ Language Binding for DOM Level 2 - in termofIDOMHi James,
>
> I went ahead and performed and submitted the refactoring. The results are
> (as posted earlier):
>
> IDOMCount and DOMCount now take the same amount of time. Not a
> surprise, as the IDOM is now behind DOM, which only adds a
> lightweight smart pointer overhead. If there is a better
> performance test for comparing, please let me know.
Check out the performance tests that AndyH did:
http://www.apache.org/~andyh/xmlbench/
I would run these on the standard 1.6 DOM and IDOM (before your mods)
and then IDOM and DOM after your mods.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Proposal: C++ Language Binding for DOM Level 2 - in termofIDOM
Posted by Lenny Hoffman <le...@earthlink.net>.
Re: Proposal: C++ Language Binding for DOM Level 2 - in termofIDOMHi James,
I went ahead and performed and submitted the refactoring. The results are
(as posted earlier):
IDOMCount and DOMCount now take the same amount of time. Not a surprise, as
the IDOM is now behind DOM, which only adds a lightweight smart pointer
overhead. If there is a better performance test for comparing, please let
me know.
The size of the release build of the VC6 DLL has been reduced to 1,364KB
from 1,560KB. This is indicative of my removing a large amount of code,
mostly due to removing the DOM implementations.
The DOM interface can still be used as always, except there were a few
methods on DOM_Document that don't exist on IDOM_Document, so given the
choice of implementing them in the IDOM or removing them, I simply removed
them. It looks like IDOM is truer to the DOM specification, and this seemed
like the right way to go, even though I wanted to create an entirely
backward compatible version of the DOM interfaces. The methods could be
added back and implementations provided on the IDOM side if that is the
wrong decision. The methods removed from DOM_Document were:
static DOM_Document createDocument();
DOM_XMLDecl createXMLDecl(const DOMString& version,
const DOMString& encoding,
const DOMString& standalone);
>From inspecting the mail list archive, I learned that the developers of IDOM
chose not to implement the equivalent to DOM_XMLDecl because it was
non-standard and those parameters where eventually going to be attributes of
the document. Because of this I took the liberty to remove "XML_DECL_NODE
= 13" from IDOM_Node's and DOM_Node's Nodetype enumerations.
I made all of my changes to an off-line copy of the source. I can make it
available to anyone interested in seeing it, and it would benefit me, and I
believe many others, if the xerces group would adopt the changes. As a
review, here are the features.
* Users of the DOM interfaces now enjoy the same performance as those of
the IDOM interfaces.
* Users can choose to work with either DOM or IDOM interfaces, and the
choice is now more one of preference. Though, those implementations that
utilize reference counting may require the use of the DOM interface.
* Different DOM implementations can now be plugged in easily. New
implementations can provide classes derived from IDOM_* abstract base
classes (overriding all methods) or existing ID*impl classes (overriding
desired methods only). For those new classes to be used all that is needed
is a new DOM_Implementation/DOM_Document pair.
* Common components like the DOMParser can be used with any DOM
implementation.
* Coupling has been removed from any specific DOM implementation, improving
maintainability as well as providing flexibility.
Regards,
Lenny
-----Original Message-----
From: James Berry [mailto:jberry@criticalpath.com]
Sent: Tuesday, February 19, 2002 4:48 PM
To: Xerces C Dev
Subject: Re: Proposal: C++ Language Binding for DOM Level 2 - in
termofIDOM
Lenny,
I think this is an interesting idea. My big concern is with performance,
though: the primary reason for IDOM was to improve the poor performance of
DOM. We would need to evaluate performance tradeoffs of your proposed
changes in order to determine whether the increased opaqueness is worth the
pain.
Is this something youve implemented? Do you have any means of generating
comparative performance data?
-jdb
On 2/19/02 2:36 PM, "Lenny Hoffman" <le...@earthlink.net> wrote:
Hi All,
I changes I proposed and submitted (IDOM/DOM integration) should be
considered here. Making the current IDOM and its interface standard will
fix its memory model, which makes it hard to have alternative
implementations. Having the flexibility to plug in different
implementations while maintaining a consistent external interface not only
helps folks like me who are creating DOM adapters to existing OO interfaces,
but also make it easier for the Xerces group to evolve the implementation as
it sees fit for performance without having to maintain parallel interfaces
like it has in the past (DOM and IDOM). In general, I believe it unwise to
standardize a memory model.
Here is the summary I provided for Bugzilla #5967:
The DOM interfaces have lightweight smart pointers to referenced counted
implementation objects, while the IDOM interfaces eliminate the smart
pointer
and the reference counting. The proposal is simply to add lightweight
smart
pointers to the IDOM implementation. Reference counting is still
eliminated,
but the smart pointers facilitate an interface that retains familiarity
with
the Java version of xerces and allows for different back ends
(implementations)
to be plugged in. One back end would be the IDOM itself, while others
could be
application specific adapters (for those that want to provide a DOM API
to
their application), database adapters, etc.
If the IDOM is standardized as is, I loose the ability to have a
standard C++ DOM interface to my product. I simply can't keep all that is
behind the DOM interface in memory at once, and I need the indirection
provided by DOM instances to keep track of what is in use and what can be
discarded. To facilitate this I added "addRef" and "removeRef" methods to
IDOM_Node that my implementation can use, but are simply ignored by the
current Xerces IDOM implementation.
If the IDOM/DOM integration is accepted, then no renaming has to occur,
and the "I" in "IDOM" can be thought to represent Implementation, for that
is what the role of all IDOM classes have become after the change. The
primary interface remains through the DOM classes and and offers the
greatest degree of backwards compatibility. Note that the way I made the
changes that current users of IDOM are unaffected, and if the DOM interface
is standardized than all that would happen to them is that they are not
using the standard interface, which they is their current situation anyway.
Meanwhile, they can adopt the DOM interfaces at their leisure without any
noticeable performance degradation.
Regards,
Lenny
Re: Proposal: C++ Language Binding for DOM Level 2 - in termofIDOM
Posted by James Berry <jb...@criticalpath.com>.
Lenny,
I think this is an interesting idea. My big concern is with performance,
though: the primary reason for IDOM was to improve the poor performance of
DOM. We would need to evaluate performance tradeoffs of your proposed
changes in order to determine whether the increased opaqueness is worth the
pain.
Is this something you¹ve implemented? Do you have any means of generating
comparative performance data?
-jdb
On 2/19/02 2:36 PM, "Lenny Hoffman" <le...@earthlink.net> wrote:
> Hi All,
>
> I changes I proposed and submitted (IDOM/DOM integration) should be considered
> here. Making the current IDOM and its interface standard will fix its memory
> model, which makes it hard to have alternative implementations. Having the
> flexibility to plug in different implementations while maintaining a
> consistent external interface not only helps folks like me who are creating
> DOM adapters to existing OO interfaces, but also make it easier for the Xerces
> group to evolve the implementation as it sees fit for performance without
> having to maintain parallel interfaces like it has in the past (DOM and IDOM).
> In general, I believe it unwise to standardize a memory model.
>
> Here is the summary I provided for Bugzilla #5967:
>
> The DOM interfaces have lightweight smart pointers to referenced counted
> implementation objects, while the IDOM interfaces eliminate the smart pointer
> and the reference counting. The proposal is simply to add lightweight smart
> pointers to the IDOM implementation. Reference counting is still eliminated,
> but the smart pointers facilitate an interface that retains familiarity with
> the Java version of xerces and allows for different back ends
> (implementations)
> to be plugged in. One back end would be the IDOM itself, while others could
> be
> application specific adapters (for those that want to provide a DOM API to
> their application), database adapters, etc.
>
> If the IDOM is standardized as is, I loose the ability to have a standard C++
> DOM interface to my product. I simply can't keep all that is behind the DOM
> interface in memory at once, and I need the indirection provided by DOM
> instances to keep track of what is in use and what can be discarded. To
> facilitate this I added "addRef" and "removeRef" methods to IDOM_Node that my
> implementation can use, but are simply ignored by the current Xerces IDOM
> implementation.
>
> If the IDOM/DOM integration is accepted, then no renaming has to occur, and
> the "I" in "IDOM" can be thought to represent Implementation, for that is what
> the role of all IDOM classes have become after the change. The primary
> interface remains through the DOM classes and and offers the greatest degree
> of backwards compatibility. Note that the way I made the changes that current
> users of IDOM are unaffected, and if the DOM interface is standardized than
> all that would happen to them is that they are not using the standard
> interface, which they is their current situation anyway. Meanwhile, they can
> adopt the DOM interfaces at their leisure without any noticeable performance
> degradation.
>
> Regards,
>
> Lenny