xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Hodges <harmo...@swbell.net>
Subject Re: Question about document type nodes and JAXP
Date Tue, 17 Oct 2000 17:06:11 GMT

----- Original Message -----
From: "Arnaud Le Hors" <lehors@us.ibm.com>
To: <general@xml.apache.org>
Cc: <xerces-j-dev@xml.apache.org>; <xerces-dev@xml.apache.org>
Sent: Tuesday, October 17, 2000 11:14 AM
Subject: Re: Question about document type nodes and JAXP


> Eric Hodges wrote:
> >
> > > In DOM Level 2, you first need to create the doctype node with
> > > DOMImplementation.createDocumentType() and then create the document
node
> > > with DOMImplementation.createDocument() to which you pass the doctype.
> > > You can't change the doctype afterwards.
> >
> > Wow, that's a serious limitation.  I'm trying rebuild an XML document
from a
> > database (and also rebuild them from serialized objects).  I usually
don't
> > know the document type until sometime after I've created the document.
> >
> > I guess I'll have to use some sort of lazy construction.  Why is DOM so
> > screwy?
>
> The problem is that depending on the type of document the application
> deals with the implementation may use very different types of classes.
> For instance, an SVG or MathML DOM implementation typically uses very
> different classes of objects for SVG and MathML nodes than a vanilla DOM
> such as Xerces DOM. In a case where an implementation supports several
> DOMs at the same time, the switch on which set of classes it uses is
> triggered at the document creation time, depending on what type of
> document the application wants to use. DOM Level 2 is designed so that
> the doctype node is the trigger. However, it is understood that this has
> serious limitations. In a parser environment such as Xerces for
> instance, you really want to create the document first and then populate
> with a vanilla doctype node whenever, and if, you encounter one. I
> haven't found any way to reconcile the two problems though. Any idea
> there is very welcome!!

I guess I don't understand what SVG or MathML DOMs are, or why their needs
are being considered for the generic DOM specification.  I thought DOM was
generic.

My suggestion:  disconnect these other DOMs from the generic DOM.  Let them
create their specific classes when they encounter the document type node if
they need to, but don't let their implementation details limit the general
usage patterns.




Mime
View raw message