xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <brett.mclaugh...@lutris.com>
Subject Re: parser-next-gen goals, plan, and requirements
Date Wed, 12 Jul 2000 18:13:42 GMT


Octav Chipara wrote:
> 
> > 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...

Just out of curiosity, you never explained why JDOM didn't work for you
(not trying to start a war - just asking the question). I can see how
the memory required for DOM caused you problems. What about JDOM did? 

-Brett

> 
> >
> > > 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
> >
> 
> ---------------------------------------------------------------------
> 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

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

Mime
View raw message