Re: StAX, JAXP 1.4

[Peter B. West]

Elliotte Harold wrote:

Peter B. West wrote:

But of course, I'm talking about Folio, which was built on a 
pull-parsing model before I had ever heard of pull-parsing, because it 
was the screamingly obvious thing to do.  It gives me acute pleasure 
to see my original design decisions vindicated by the the development 
of the StAX API, and the current surge of interest. So, all of this, 
and more, _is_ the case.  My invitation stands.




I haven't looked at Folio yet. Perhaps it's screamingly obvious that it 
needs a pull model. If so it's the first such application I've 
encountered.  The really useful pull models are implemented on top of 
tree structures, and provide random access. I've yet to see a case where 
a one-way streaming pull parser did anything that couldn't be 
accomplished equally easily and efficiently with a push parser.


The primary benefit to pull parsers is that some developers either don't 
understand or simply don't like the observer design pattern as embodied 
in push parsers, and prefer the iterator design pattern as embodied in 
pull parsers. Whatever floats your boat. However there's no evidence 
that either pattern is in any way fundamentally superior to the other, 
except as a matter of developer taste.


As a practical matter, existing SAX parsers are much better optimized 
and debugged than existing StAX parsers. They're simply a more mature 
product.


Elliotte,

We're seriously OT here, so I'll off-line my response.

Peter

--
Peter B. West 
Folio 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: StAX, JAXP 1.4

[Elliotte Harold]

Peter B. West wrote:

But of course, I'm talking about Folio, which was built on a 
pull-parsing model before I had ever heard of pull-parsing, because it 
was the screamingly obvious thing to do.  It gives me acute pleasure to 
see my original design decisions vindicated by the the development of 
the StAX API, and the current surge of interest. So, all of this, and 
more, _is_ the case.  My invitation stands.



I haven't looked at Folio yet. Perhaps it's screamingly obvious that it 
needs a pull model. If so it's the first such application I've 
encountered.  The really useful pull models are implemented on top of 
tree structures, and provide random access. I've yet to see a case where 
a one-way streaming pull parser did anything that couldn't be 
accomplished equally easily and efficiently with a push parser.


The primary benefit to pull parsers is that some developers either don't 
understand or simply don't like the observer design pattern as embodied 
in push parsers, and prefer the iterator design pattern as embodied in 
pull parsers. Whatever floats your boat. However there's no evidence 
that either pattern is in any way fundamentally superior to the other, 
except as a matter of developer taste.


As a practical matter, existing SAX parsers are much better optimized 
and debugged than existing StAX parsers. They're simply a more mature 
product.



--
Elliotte Rusty Harold  [EMAIL PROTECTED]
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

Re: StAX, JAXP 1.4

[Peter B. West]

Elliotte Harold wrote:

Peter B. West wrote:


So I exaggerated.  But how many better applications can you find me for
StAX than processing XSL-FO?  If StAX has no application here, it has no
application.  Is that what you're saying?



You're asking the question backwards. We should not be asking, "Is 
XSL-FO the best possible use case for StAX?" We should be asking, "Is 
StAX the best possible API for XSL-FO?"


One certainly good do write FOP on top StAX, but you can also do it with 
SAX; and since it's already working with SAX I see no particular reason 
to throw away the working SAX code and replace it with StAX. If we were 
starting from scratch, and if the developers were more familiar with 
StAX than SAX, and if StAX parsers were as mature, proven, and 
ubiquitous as SAX parsers, then writing FOP on top of StAX might be 
reasonable. However none of that's the case.




But of course, I'm talking about Folio, which was built on a 
pull-parsing model before I had ever heard of pull-parsing, because it 
was the screamingly obvious thing to do.  It gives me acute pleasure to 
see my original design decisions vindicated by the the development of 
the StAX API, and the current surge of interest. So, all of this, and 
more, _is_ the case.  My invitation stands.


Don't let your feet get wet, Elliotte.

Peter
--
Peter B. West 
Folio 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: StAX, JAXP 1.4

[Elliotte Harold]

Peter B. West wrote:


So I exaggerated.  But how many better applications can you find me for
StAX than processing XSL-FO?  If StAX has no application here, it has no
application.  Is that what you're saying?


You're asking the question backwards. We should not be asking, "Is 
XSL-FO the best possible use case for StAX?" We should be asking, "Is 
StAX the best possible API for XSL-FO?"


One certainly good do write FOP on top StAX, but you can also do it with 
SAX; and since it's already working with SAX I see no particular reason 
to throw away the working SAX code and replace it with StAX. If we were 
starting from scratch, and if the developers were more familiar with 
StAX than SAX, and if StAX parsers were as mature, proven, and 
ubiquitous as SAX parsers, then writing FOP on top of StAX might be 
reasonable. However none of that's the case.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

Re: StAX, JAXP 1.4

[Peter B. West]

Elliotte Harold wrote:

Peter B. West wrote:


Fopsters,

Some of you may be aware of the activity going on around StAX.  Java 
1.6 (Mustang) was to have included JAXP 1.4, but that looks to be on 
hold until Dolphin.  However, StAX will be part of it, and soon 
enough, SAX will be a dim memory.




Yeah, right. I give this claim about as much credence as I gave the 
claims that schemas were going to replace DTDs. StAX isn't as 
disastrously bad as schemas were, but it certainly hasn't justified the 
hype either. So far I've seen approximately no evidence that it provides 
any noticeable improvements over SAX. Some people find StAX easier to 
use the SAX for some use cases, but not all. I suspect Sun never saw the 
performance improvements they were hoping for from StAX which is why 
they're now off and running up another wrong path called "Fast Infoset". 
(I was just looking at some 3rd party performance numbers on that this 
morning, and guess what? It isn't working out either.)


I don't think SAX is the ultimate in XML performance, but I suspect even 
a factor of two improvement over SAX is going to require something a lot 
more radical than StAX.


Elliotte,

So I exaggerated.  But how many better applications can you find me for
StAX than processing XSL-FO?  If StAX has no application here, it has no
application.  Is that what you're saying?

Peter

--
Peter B. West 
Folio 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: StAX, JAXP 1.4

[Elliotte Harold]

Peter B. West wrote:

Fopsters,

Some of you may be aware of the activity going on around StAX.  Java 1.6 
(Mustang) was to have included JAXP 1.4, but that looks to be on hold 
until Dolphin.  However, StAX will be part of it, and soon enough, SAX 
will be a dim memory.




Yeah, right. I give this claim about as much credence as I gave the 
claims that schemas were going to replace DTDs. StAX isn't as 
disastrously bad as schemas were, but it certainly hasn't justified the 
hype either. So far I've seen approximately no evidence that it provides 
any noticeable improvements over SAX. Some people find StAX easier to 
use the SAX for some use cases, but not all. I suspect Sun never saw the 
performance improvements they were hoping for from StAX which is why 
they're now off and running up another wrong path called "Fast Infoset". 
(I was just looking at some 3rd party performance numbers on that this 
morning, and guess what? It isn't working out either.)


I don't think SAX is the ultimate in XML performance, but I suspect even 
a factor of two improvement over SAX is going to require something a lot 
more radical than StAX.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

StAX, JAXP 1.4

[Peter B. West]

Fopsters,

Some of you may be aware of the activity going on around StAX.  Java 1.6 
(Mustang) was to have included JAXP 1.4, but that looks to be on hold 
until Dolphin.  However, StAX will be part of it, and soon enough, SAX 
will be a dim memory.


Obviously, Folio (nee FOP Alt-Design), built on a stream parsing model, 
will eventually retro-fit StAX and, later, JAXP 1.4.  It's not high on 
my priorities just now.


However, if someone wants to steal a march in getting a handle on what 
will soon be the standard way of parsing XML, feel free to do the 
retro-fit on Folio.  It's an existing stream-parsed application, so the 
structure requires no changes.  If you're interested,contact me directly.


Peter
--
Peter B. West 
Folio 


smime.p7s
Description: S/MIME Cryptographic Signature