Re: xxxML on top of, embedded in XML

At 02:04 PM 4/30/98 -0400, David Megginson wrote:

>The DOM provides an object model for generic documents, and such a
>model will be very useful for general formatting, editing, archiving,
>and searching processes.
>
>However, it seems to me that PGML implies a very different object
>model of hierarchical and linked graphic components, and that it would
>be inefficient to build a DOM tree first, only to tear it down and
>build a vector-graphics object tree in its place.  Why not design a
>PGML object model, and build it directly from an event-based API?  The
>difference in overhead for a large (say, 1GB) vector graphics file
>will be enormous.

I suspect that we agree, but we may differ on terminology. I am planning to
build a PGML object model. While it will implement the generic XML DOM API,
I don't expect it to create a priori the full tree for exactly the reason
you point out. The PGMLPathElement will provide access to its path data
without requiring a client application to iterate through a bunch of path
data elements. Internally, the PGMLPathElement will store the path data in
a typical display list. If a client app does call on the generic API to
iterate through the path's children nodes, only then would the nodes be
instantiated.

>As I mentioned above, the DOM is a solution to a specific problem.
>Every XML document implies some kind of object model -- sometimes (as
>in the case of a technical manual, a poem, or a novel), the DOM will
>be a very good match; other times (as in the cases of serialised
>components, vector graphics, or an XSL stylesheet), the DOM will be
>too far from the optimal object model.

Agreed, but just as the HTML DOM builds on the Core DOM, it will be useful
for the PGML DOM to build on common functionality.

Richard

Received on Friday, 1 May 1998 11:53:02 UTC