xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Octav Chipara <ochip...@cse.unl.edu>
Subject Re: parser-next-gen goals, plan, and requirements
Date Wed, 12 Jul 2000 18:01:51 GMT

> Octav Chipara wrote:
> > 
> > 1) True! ... But my only problem is that when you are using various
> > subsets of DOM, are you still having a compliant W3C recomandation? I
> > believe that we should actually develop a new set of interfaces rather
> > then using a subset of DOM! If we are starting from scratch we might get
> > better results than trying to subset DOM! Many of us try to build
> > applications which understand XML for embedded systems and I see great
> > value in having a DOM-like implementation for such systems. Do you believe
> > using a subset is good enough?
> The Xerces DOM implementation currently supports almost all of the DOM
> Level 2. This is the Core + several optional modules, such as mutation
> events, traversal, etc... Every optional module makes the whole thing
> bigger in memory and slower. To start with, we can have an
> implementation with just the Core. But we can do much more. This
> includes things like being readonly, and/or not providing fast random
> access a la getChildNodes().item(i). We currently have a cache for that
> which costs us in memory. There are many things like that we can do, all
> within the scope of a compliant implementation. And as we work on this,
> if there is anything in the DOM that gets in the middle we can always
> bring it up to W3C and look for a solution there.

This exactly my point and I agree with your attitued ... But I do not
believe that W3C has to solve our problems. Unfortunately :-). My worries
are that even the core implementation is too big, that's why I would
propose if someone wants to take a look into other possible solutions
except DOM and JDOM. When W3C made the recomandation for DOM I do not
belive that they had in mind that DOM would be used for embedded systems.
My point is that SAX would be the solution for such small systems but it
does not have the necessary processing power that I would like... and I
was not able to cutdown the DOM size to be resonable for an embedded
system. :-(. That's why I was trying to propose to move away from DOM and
make something innovative... 

> > 2) The second part regards a higher level tool which I would love to have.
> > Something to map the structure of a XML document directly on a structure
> > defined in a programming language ...
> > ...
> > Do you understand what I'm trying to say?
> Sure. There are already several tools that do that. I don't have any
> pointers handy though, but I'm sure someone else on this list has some.
> -- 
> Arnaud  Le Hors - IBM Cupertino, XML Technology Group
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org

View raw message