Re: XML too hard for programmers?
Elliotte Rusty Harold wrote: > At 4:43 PM +0100 3/17/03, Robin Berjon wrote: >> In fact, there has been some work within the Perl community to address >> the problems that programmers evidently face when using the dominant >> SAX/DOM/XPath/XSLT combo. > > I strongly suspect that a large part of the problem is that exactly none > of these were designed with Perl in mind. As DOM has shown beyond any > doubt, cross-language APIs are a disaster that satisfy no one. > Interoperability needs to be achieved at the XML level, not the API > level. I don't care which API or language you use to process your XML > documents as long as I can send you XML and receive XML back. I don't think that's really the problem, Perl's flexibility means that it can pretty much adapt to whatever API is fed into it. I must say that after hearing all the hype about Java's XML support, I was very much disappointed when I started using it for real world projects. I ended up porting some Perl things such as XML::SAX::Machines. Besides, SAX was largely remodelled to produce PerlSAX which is more idiomatic. XPath and XSLT are very much appreciated within the community, and DOM interfaces tend to also be slightly modified here and there (eg using native arrays instead of live nodelists that tend to bite). > There are a few general types of APIs (tree-based, streaming pull, > streaming push, data binding) and these types have different strengths > and weaknesses. I think that's precisely one of the issues: in order to program for XML you need to know all four of those APIs and languages. They are adapted to different needs and it is often required to switch between them. My typical large scale XML project will usually need to use at least both trees and streams, and there's some mismatch in the way it happens. That's why I think that research such as Barrie's into approaches that try to get the best of both worlds is very interesting. I've also been globally unhappy with data binding approaches, mostly because they tend to revolve around an XML Schema view of XML. I think I'd be happier writing a binding document that performs a simple mapping, perhaps as an RNG extension. I haven't had time to explore that further though. Sometimes I also have the impression that XML programming feels as unnatural as RDBMS programming, which I would classify as an issue as well :) > The most generic experiences with such APIs may cross > language boundaries (e.g. use a streaming API when documents are very > big relative to memory) but anything beyond that is misdirected effort. > SAX is a good Java API. It is not a good Perl API, and Perl should not > slavishly imitate it. I agree, and that's whay we did. I'm reasonably happy with PerlSAX but then I took part in the spec and implemented parsers, writers, filters, etc for it so I'm probably biased :) I think the issue is not the API itself but rather that people would rather not have to go to event driven programming. It looks as if libxml's pull API is getting wrapped so we'll see how that goes. I think one thing that hasn't been given sufficient attention to is DOM Traversals which I find very naturaly to work with. -- Robin Berjon <robin.berjon@e...> Research Engineer, Expway http://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format