EDOM (Eiffel DOM implementation)

Introduction

EDOM is a freely-available Eiffel binding an implementation of the World-Wide-Web Consortium's Document Object Model. It supports the following DOM modules:

Core levels 1.0, 2.0 and 3.0 (April 2002 draft version).
Range level 2.0.
Traversal level 2.0.
XPath level 3.0.
A partial implementation of Load and Save 3.0 (April 2002 draft version).

The initial implementation is based upon Apache Xerces C++ 2.2.0. This features validation against both DTDs and W3C XML Schema Definitions.

Support for multiple implementations is present (in principle - I have implemented the proposed DOMImplementationRegistry).

XSLT is also (optionally) supported. As far as I know, there is no standard for invoking an XSLT processor, other than JAXP, so I'm very much feeling my way here. Comments welcome.

The XSLT implementation is Xalan C++ 1.5. This comes with a full set of extension functions, plus parts of the EXSLT library. See the Xalan documentation for details.

Schematron validation is supported (assuming you have installed XSLT support) via Schematron-Basic and XSLT. Schematron rules can also be embedded in W3C XSD schemas (and in RLEAX-NG grammars, but EDOM does not yet do validation with RELAX-NG grammars).

All DOM level 3.0 interfaces are experimental, and liable to change. The XSLT interface is not yet complete.

This release uses the GOBO tools geant and gexace. Despite that, only ISE works at present. I made an attempt at getting it to work with SE. The Eiffel code compiled, but then I was faced with getting the C++ code to compile. Anyway interested in taking on this task, then email me with your sourceforge id. VE doesn't yet support INTEGER_16, so there is more effort involved there.

Installation

Install the latest version of GOBO (3.2 or later is required), if you haven't done already.
Install Xerces-c 2.2.0 (2.3.0 is not yet supported). I always install from source. If compiling with MS VC++, then be sure to specify the /GR option.
Ensure that the environment variable XERCESCROOT is set, as per the Xerces C++ installation instructions.
Optionally, install Xalan 1.5.0 or later.. Ensure XALANCROOT is set. For instance, if you unpack a source distribution into /opt, then XALANCROOT should point to /opt/xml-xalan/c .
Install Pathan 1.2.1. Windows users are advised to install from this binary.
Download and unpack the EDOM distribution into a directory, and set the environment variable EDOM accordingly (e.g. if you unpack into /opt, then set EDOM to /opt/EDOM)
Change to the $EDOM directory, and type geant install (or geant install-without-xslt if you chose not to install Xalan-c 1.5).
If you chose not to install Xalan-c 1.5, then you must edit tests/build.eant. near the bottom of this file, in target init, there is a line which sets the value of xalan to true. Change this value to false.
Edit $EDOM/tests/system.xace and $EDOM/tests/xslt/system.xace so as to change any lines marked via comment if necessary.
Change to the tests sub-directory of the EDOM directory.
Type: geant test (or geant test_debug if you are the cautious type).
If all tests pass then installation is succesfull. Ignore any other output prior to the final summary
Now if you installed Xalan-c 1,5. change to directory $EDOM/tests/xslt, and type: geant test (or geant test_debug if you are the cautious type).
Email me to let me know your opinions, intentions, etc.

Design issues

Naming conventions

Since the DOM is defined using CORBA idl, I thought it appropriate to use the same names that MICO/E would generate from the idl files.

Directory structure

The test programs are in the EDOM root directory. The library is packaged into the following directories:

dom: DOM Core module
ls: DOM Load and Save module
ranges: DOM ranges module
traversal: DOM traversal module
xpath: DOM xpath module
xslt: XSLT library - still in development
data: Data files used by the test programs (.xml, .xsd etc.)
schematron: Redistibuted XSLT files for Schematron validation.
xercesc: Supporting utilities for the Xerces C++ implementation
tests: An (eventually) comprehensive test suite.

Each of the DOM module directories consist largely of deferred classes (the registry, and some facility classes are exceptions). Each one has a xercesc sub-directory, which contains the Xerces C++ implementation of those interfaces. The xslt directory has a xalanc sub-directory for the Xalan C++ implementation. This is nowhere near working yet.

Implementation Status

Unless stated otherwise, interfaces have not been tested.

DOM Core 3.0 (April 2002 draft)

Interface	Status	Reason
DOMException	Fully implemented and tested.
DOMImplementationSource	Fully implemented.
DOMImplementation	Fully implemented.
DocumentFragment	Fully implemented.
Document	Fully implemented.
Node	Fully implemented	getUserData and setUserData have wrong signature.
NodeList	Fully implemented and tested.
NamedNodeMap	Fully implemented.
CharacterData	Fully implemented.
Attr	Fully implemented.
Element	Fully implemented.
Text	Fully implemented.
Comment	Fully implemented.
UserDataHandler	Programmer implements.	Implemented sucessfully as a test.
DOMError	Mostly implemented.	relatedError is not yet implemented, as Xerces C++ does not implement it.
DOMErrorHandler	Programmer implements	Implemented succesfully as a test.
DOMLocator	Fully implemented.
CDATASection	Fully implemented.
DocumentType	Fully implemented.
Notation	Fully implemented.
Entity	Fully implemented.
EntityReference	Fully implemented.
ProcessingInstruction	Fully implemented.

DOM Load and Save 3.0 (April 2002 draft)

Interface	Status	Reason
DOMSystemException	Implemented.	Although W3C have not yet specified what it should look like.
DOMImplementationLS	Fully implemented via Xerces C++. All tested except createDOMInputSource.
DocumentLS	Not implemented	Xerces C++ does not implement it (and DOMBuilder/DOMWriter provide this functionality) Could easily be implemented in terms of DOMBuilder plus DOMWriter
DOMInputSource	Partially implemented	Xerces C++ implements some of the functionality. To be reviewed.
LSLoadEvent	Not implemented or even declared (as it depends on events module)	Xerces C++ does not implement it, as it does not support asynchronous parsing.
LSProgressEvent	Not implemented or even declared (as it depends on events module)	Xerces C++ does not implement it, as it does not support asynchronous parsing.
DOMEntityResolver	Not implemented	Not implemented - dependent on DOMInputSource.
DOMBuilderFilter	Implemented, but will not work	Xerces C++ will throw an exception if you try to set the filter. When Xerces C++ implements this, one change to dom.h is needed (umcomment base class). Hm. Check this - probably not true now.
ParseErrorEvent	Not implemented or even declared (as it depends on events module)	Xerces C++ does not implement it.
DOMBuilder	Mostly implemented. Tested where implemented.	parse and parseWithContext depend on DOMInputSource entityResolver attribute depends on DOMEntityResolver filter will not work.
DOMWriter	Fully implemented. Fully tested.
DOMWriterFilter	Programmer implements.	Implemented sucessfully as a test.

DOM Traversal 2.0

Interface	Status	Reason
NodeFilter	Programmer implements.	Implemented sucessfully as a test.
NodeIterator	Fully implemented. Partially tested.
TreeWalker	Fully implemented. Partially tested.
DocumentTraversal	Fully implemented and tested.

DOM Range 2.0

Interface	Status	Reason
Range	Fully implemented. Partially tested.
RangeException	Fully implemented.
RangeExceptionCode	Fully implemented.
DocumentRange	Fully implemented and tested.

EDOM (Eiffel DOM implementation) 1.3

Introduction

Licenses

Installation

Documentation