Re: Standard API to XSL processors

Subject: Re: Standard API to XSL processors
From: Tyler Baker <tyler@xxxxxxxxxxx>
Date: Wed, 13 Jan 1999 20:02:08 -0500
keshlam@xxxxxxxxxx wrote:

> >James has claimed that the DOM is not suitable to be the internal
> >representation for one random access application - the XSL processor
> itself.
>
> I'm not sure I want to ask "why not". I do want to remind folks that if the
> DOM doesn't provide something that XSL needs, and you expect that other XML
> applications may also need it, you should liaise with the DOM WG to explore
> solutions and alternatives. If you've got a divergence of basic assumptions
> about the conceptual structure of XML that this doesn't resolve, get the
> Infoset or Syntax WG's involved and fold their conclusions back into both
> DOM _and_ XSL.
>
> The DOM is not unchangable. It can be extended. It can even be corrected,
> if you can demonstrate that something it now does is a serious problem. And
> I think the DOM developers see XSL as a useful testcase; if anything,
> there's a wish that XSL had been further along and in a better position to
> provide active feedback as the DOM evolved.
>
> If W3C comes out with a set of XML standards that don't fit together -- not
> necessarily perfectly, but without undue force-fitting --  someone didn't
> do their job.

When you have some abstract data-structure like the DOM, you can index it
internally or externally.  My experience has been that indexing the DOM
externally is not too big a cost, and is practically no cost if you index the
DOM while you are building the DOM (in effect what you would do if you indexed
it internally anyways).  I don't really feel that you need to bloat the DOM
with all sorts of indexing to support better searching to make it useful since
it is easy and relatively efficient to do externally.  If you have a huge
in-memory DOM tree on the order of many megabytes of RAM, then you are probably
better off with a native database solution or else redesigning your system to
break you monolith DOM tree into a bunch of more manageable Documents.

On another note, if there is one kind of method that would help out app
designers with the DOM is some sort of mutation listener for a node, where when
a node is mutated it fires off an event telling the host application that a
mutation has occurred.  This would not be necessary when building a DOM tree
from a file, but any mutations after that you need to have some mechanism for
so you can update any special node observers.

Other than that, even though I wish there were subtle some changes to make
processing faster in Java like returning character arrays and not strings for
node values, I think the DOM does the job 95% of the time.

Tyler


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread