xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: parser-next-gen goals, plan, and requirements
Date Wed, 12 Jul 2000 22:50:27 GMT

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

Those who are interested in XPath support, should please look at the Xalan2
implementation, in the light of this being a xml-support library, rather
than just part of the XSLT project.  It still needs a fair amount of work,
but now is the time to figure out what is wrong with the overall design
(please get involved!).  Note that it is very different from Xalan1's
implementation.

A couple of notes:

1) I would like to replace the existing XPath parser, which was built under
different constraints than exist currently (it was originally built to be a
pure interpreter), with a java yacc equivalent parser, mainly because I
think it will be *much* easier to maintain in general and to expand for
XSLT2.  Pretty easy to do... a day or two's work.  If anyone want's to
volunteer for this, the help would be most welcome.  I'm uncertain if
intermediate code (the OpMaps) should still be created for the purpose of
optimization.

2) A compiled version of the paths needs to be created, which will replace
the expression trees in compiled mode (but the existing expression trees
will need to remain, for running when their is no compiler available or it
doesn't make sense to compile).  I think this is pretty easy to do.

3) The node iterators and tree walkers (based loosely on DOM2's traversal
interfaces) are the really interesting heart of the system... processing an
XPath in document order (without creating a list and then sorting) is *not*
easy to do (so don't yell at me about complexity... I know this ground very
well... but note that the code is cleanly modularized and, I feel is much
simpler than the old SimpleNodeLocator in many ways).  However, they will
be optimized so that simple LocationPaths and Unions are done very simply.

-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 06:18 PM                                                  
                               
                    Please respond to                                                    
                               
                    general                                                              
                               
                                                                                         
                               
                                                                                         
                               





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
>
> >
> > --
> > Stefano Mazzocchi      One must still have chaos in oneself to be
> >                           able to give birth to a dancing star.
> > <stefano@apache.org>                             Friedrich Nietzsche
> > --------------------------------------------------------------------
> >  Missed us in Orlando? Make it up with ApacheCON Europe in London!
> > ------------------------- http://ApacheCon.Com ---------------------
> >
> > ---------------------------------------------------------------------
> > 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
>
> ---------------------------------------------------------------------
> 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

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






Mime
View raw message