Hi gurus and nubys,
I’m just trying to understand the Xml Pull API, cause it seem quite
interesting and easy to grok.
I know that REXML has experimental support fro this api,
I wonder how much experimental it is, and if somebody else used it.
On a sidenote, I’d like to hear from the XML gurus out there what they
think of this API (and on a sidesidenote , what is the reference for
this kind of api, xmlpull.org seems quite unmantained…)
TIA
sidesidesidenote: I believe there should be a
alias next pull
somewhere in the PullParser definition.
it’s not there as of
REXML:
Date = “+2003/346”
Version = “2.7.3”
il Mon, 15 Mar 2004 21:53:12 GMT, gabriele renzi surrender_it@remove.yahoo.it ha scritto::
gabriele renzi surrender_it@remove.yahoo.it wrote in message news:739c50l79fn0ffa9oui6dfpjk5jvot4cf2@4ax.com…
I know that REXML has experimental support fro this api,
I wonder how much experimental it is, and if somebody else used it.
I’d be careful around:
Otherwise, it should be fairly complete.
On a sidenote, I’d like to hear from the XML gurus out there what they
think of this API (and on a sidesidenote , what is the reference for
this kind of api, xmlpull.org seems quite unmantained…)
I was a real doubter when I first started it, but I’m starting to
really like the SAX2 and Pull APIs. Specifically, I’d like to get
pattern matching working better in SAX2. They’re both really nice
APIs if you aren’t doing any document manipulation, or if you don’t
need to process the entire document.
There isn’t really any reference for the pull API. Somebody requested
it, so I hacked it together. As usual, rather than looking at any
specs (Specs? We don’t need no stinking specs) I asked people to send
me examples, pseudocode, that they’d write if they had access to this
API. This is an extrapolation of test-first development, and I think
it produces better APIs. It gets the developer looking at the problem
from the user’s POV, rather than from an implementation POV, which
helps to keep the implementation details from leaking into the API.
Ironically, the Pull parser became the core parser upon which all of
the other parsers are based. This is because you can implement a tree
or stream parser using a pull parser, but not vice versa – at least,
not without some contortions.
The SAX2 API was a different matter, because the SAX2 spec is really
simple, loose, and actually pretty well written. It emphasizes
behaviors rather than a specific API, so I tried to conform to it.
Finally, most of the bug reports I get are still for the Document API.
I get very, very few bug reports on the SAX2 or the Pull Parser APIs.
Since I know there are deficiencies in those APIs, this tells me
that not many people are using them, and/or are not using them
heavily.
— SER
thanks for thew answer, this was very interesting.
Finally, most of the bug reports I get are still for the Document API.
I get very, very few bug reports on the SAX2 or the Pull Parser APIs.
Since I know there are deficiencies in those APIs, this tells me
that not many people are using them, and/or are not using them
heavily.
Probably the big “This API is experimental, and subject to change.”
did not help 
But i believe that this api is little used even in non-ruby worlds.
BTW, Am I wrong thinking that there should be a next() method in
PullParser instances ?
il 17 Mar 2004 17:45:33 -0800, ser@germane-software.com (Sean Russell) ha scritto::
gabriele renzi surrender_it@remove.yahoo.it wrote in message news:vkri501d1a2rm2acaeb0s6vt0702tj3q2a@4ax.com…
Probably the big “This API is experimental, and subject to change.”
did not help
True… but even when REXML was in its infancy, and everything was
experimental and subject to change, I got more bug reports on the
Document API than I do on SAX and Pull now.
But i believe that this api is little used even in non-ruby worlds.
You may be right. Like procedural programming, it may not be the
best, but for some reason, it seems to be the easiest to understand.
BTW, Am I wrong thinking that there should be a next() method in
PullParser instances ?
I could alias next() to pull()… I want to be careful about adding
cruft to the API that doesn’t add functionality. A single alias, by
itself, wouldn’t bloat the package much, but a bunch of tiny features
adds up.
How much do you want it? What does everybody else think about it?
Get a few people to email me requesting it, or make a convincing
argument, and I’ll add it.
— SER