DOM and Xapi-J

[John Tigue]

Some questions have arisen as to the possibility of conflicting overlap
between the DOM and Xapi-J. For those areas where they do overlap, I see
Xapi-J as eventually being a proper subset of the DOM. For example:

The DOM is language independent. Xapi-J is Java only.

The DOM is platform independent. Xapi-J is for the Java platform only.
Xapi-J is designed to be a stylistically consistent extention to the JDK
which embeds it even further into Java e.g. see the recent thread
entitled "Xapi-J: an architectural detail"

The DOM covers HTML and XML. Xapi-J only covers XML.

Eventually, I would think that Xapi-J compliant processors would be seen
as having a DOM-compliant object model of an XML document because they
will eventually use the DOM's Java language bindings exactly. There are
also many other features of the DOM requirements which are not reflected
in Xapi-J. The parts of Xapi-J related to how a developer instantiates a
processor and optionally get ESIS parse events out of one of these
JavaBeans does not overlap with the DOM work.

I think we can declare Xapi-J 1.0 complete at any time now. When the DOM
is done I think Xapi-J should be reved to be a direct subset of the
DOM's object model using the DOM's object model and method signatures
exactly. That is the only part I see where there is overlap and it would
be a shame to have two very similar but different object models of an
XML document. The original goal of Xapi-J was to come up with a unified
model/api for Java developers who are using/writing XML processors. To
not reflect the work of the DOM WG would defeat the whole idea.

--
John Tigue
Sr. Software Architect
DataChannel
http://www.datachannel.com
jtigue at datachannel.com
206-462-1999

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 263 bytes
Desc: Card for John Tigue
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970808/3df6ada0/vcard.vcf