[
Lists Home |
Date Index |
Thread Index
]
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@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
