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 22:23:10 GMT


Guys,

1) If we keep everything modular we could add as much as you want but lets
concentrate now on should be the core for a new generation of parsers.
Let's put XPath, JDOM, DOM (verious levels of implementations) as
separable modules. Who needs or want them they can add to the parse. Let's
keep it as small as possible and put the rest of the stuff later. 
2) I propose that we could agree firs upon some design ideas and then get
down to what should or should not be on. Defining this might save us a lot
of trouble ... after identifying what we want to do will be much simpler
to figure out what is supposed to be in and what is supposed to be out.

	1. the parser must have a modular architecture
	2. the core-parser should be kept to minimum

How do you feel about this?

- Octav


On Wed, 12 Jul 2000, Brett McLaughlin
wrote:

> 
> 
> Scott Boag/CAM/Lotus wrote:
> > 
> > > Additionally, based on Scott's reaction ;-), he wouldn't add in support
> > > for XPath on JDOM.
> > 
> > Please don't misinterpret my inappropriate remarks.  The issue is, XPath
> > needs to walk a tree model, or else all the code would have to feel through
> > an adapter, which would be a problem, I think.  As far as I can tell, DOM
> > is the appopriate tree model for XPath to work with.  (I did discuss this
> > with you early in the JDOM incarnation).
> 
> Right - that mail crossed this in the nebulous world of ISPs... no sweat
> ;-)
> 
> > 
> > Please read my other email.  I would love to have Xalan's XPath
> > implementation work with JDOM.  I just don't see how to do it right now,
> > unless you implement a DOM subset, which wouldn't be hard, in my opinion,
> > or unless I made a total forked version of XPath.  If you have other ideas,
> > I would be glad to brainstorm with you to come up with a solution.
> 
> Yeah, and it looks like XPath is going to go into the parser level,
> allowing us to really think about how best to do that... Good future, as
> far as I can tell.
> 
> > 
> > Again, sorry for my original remark -- I shot off my mouth without enough
> > care or respect.  Hopefully you'll get over your anger with me...
> 
> Definitely ;-)
> 
> -Brett
> 
> > 
> > -scott
> > 
> > 
> >                     Brett McLaughlin
> >                     <brett.mclaughlin@l        To:     general@xml.apache.org
> >                     utris.com>                 cc:     (bcc: Scott Boag/CAM/Lotus)
> >                                                Subject:     Re: parser-next-gen
goals, plan, and requirements
> >                     07/12/2000 10:07 AM
> >                     Please respond to
> >                     general
> > 
> > 
> > 
> > Stefano Mazzocchi wrote:
> > >
> > > Donald Ball wrote:
> > > >
> > > > I'd like to see XPath and XInclude support built in to Xerces as
> > > > modules.
> > >
> > > +1 for XInclude and XBase (they do together), as well as a way to
> > > extract XLink information from the file, if found.
> > >
> > > -1 for XPath, it should belong to Xalan2
> > 
> > I'm actually in disagreement here - I know in JDOM, people want to be
> > able to look up nodes/elements/attributes using XPath. Additionally,
> > more and more APIs are using XPath outside of XSL/T. To include it as
> > part of Xalan forces users to get an entire jar to do that.
> > Additionally, based on Scott's reaction ;-), he wouldn't add in support
> > for XPath on JDOM. That's another reason. Still, I think users that know
> > XPath would love to do:
> > 
> > Element specific = root.getChild("foo/@bar='1'");
> > 
> > Not having to carry around XSL/T weight to do this is a major advantage,
> > and prepares us for the APIs that use XPath outside of just
> > transformations.
> > 
> > -Brett


Mime
View raw message