OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Can xpath replace DOM/SAX?

[ Lists Home | Date Index | Thread Index ]

I'm working on a XML/web services related project. It's interesting to note that all my XML processing needs can be met by xpath. xpath also is much simpler to program than DOM/SAX. This makes me wondering if one can directly build xpath engine and bypass the parsing step.
 
Before going down the route, I'd like to hear your expert's view on this subject. If I just implement xpath directly to access XML files, without a parser layer, would I run into problems later? Even though I don't see a need for DOM/SAX now, I'm afraid that in the future there my be something that require them. It would be great if you can provide me a common case of where xpath is not sufficient and a parser is needed.
 
I think the same thought has been applied by Java binding people. In my original view of XML processing, the flow goes like:
    XML file --> parsing --> binding or accessing
 
Java binding people skiped the parsing step. Is it a good idea for accessing people to also skip the parsing step?
 
A bolder hypothesis (with limited knowledge) is: one can always find a shortcut to bypass parsing, to serve higher level application's needs. If it's true then DOM/SAX will gradually disappear from real products, because of their respective shortcomings. xpath seems to be a better step stone for lots of other processing to base on.
 
Thanks,
 
Hui




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS