to whom was that comment addressed?

Sent from my iPod

On 14 Aug 2008, at 16:30, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Yah, we can hook you up Tatu. If you're making something else you're trying to put us in the same boat as Aaron. Your chance of getting us to use another XML parser is zero.

On 14-Aug-08, at 8:02 AM, Daniel Kulp wrote:



Personally, I would wrather see these classes added to woodstox. It's then a single dependency I need. Not a "depend on this if we want speed, depend on that if we want verbatim" type thing. It could just be a property on the
InputFactory as to which woodstox would return.

Dan


On Thursday 14 August 2008 10:53:42 am Stephen Connolly wrote:
Oh, yes I forgot to add:

By driving from the event API we can store all the verbatim information in
the XMLEvent objects.

Then our XMLEventWriter sees these XMLEvent objects and (when in verbatim
mode) says they are unmodified, so write them unmodified.

If you create a new or replacement XMLEvent object the XMLEventWriter says... ahhh not one that was input verbatim, so I'll output in XML spec
way.

I also want to add some heuristics to determine when writing what the maximum line length is, and how many spaces to indent things by so that elements which did not originate from the input are formatted consistently.

If you think all that fits with StAX's ethos, I'm fine for merging.... but
I think this should really be a separate project, as it's a separate
purpose. Codehaus already has StAX and Woodstox.... come on let's have a third JSR-173 implementation on codehaus (XEVPP - XML Events Verbatim
Pull-Push)

-Stephen

On Thu, Aug 14, 2008 at 3:47 PM, Stephen Connolly <

[EMAIL PROTECTED]> wrote:
The problem, as I see, with StAX is that they all start from the minimal
parser and build up.

i.e.

XMLInputStream accesses the stream directly.

XMLEventReader wraps the XMLInputStream.

So if you follow the StAX API for the minimal parser, you are forced to either throw away the information you need to do _verbatim_ rewriting of XML, or completely ignore the StAX API methods for XMLInputStream in the XMLEventReader wrapper (which is really a duplication of code bad smell)

The parser I'm writing is wired the other way around...

So

XMLEventReader access the stream directly

XMLInputStream wraps the XMLEventReader.

The side-effect is that XMLInputStream is slower... but you picked this JSR-173 implementation because you wanted it to give verbatim roundtrip
output... not for performance.

Also, due to the way JSR-173 is written, you are stuck if you want to do
the round-trip with your XMLInputStream as the JSR api throws away
information you need.

On Thu, Aug 14, 2008 at 3:39 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 14-Aug-08, at 7:33 AM, Stephen Connolly wrote:

It's a bit of a hack....

I have another XML Pull Parser in the works that will do this verbatim no problem.... but convincing a despot to approve the project request
is a bit
trickier!

Can you integrate it into StAX?


The current implementation is the ModifiedPomXMLEventReader which takes

an
XMLEventReader, wraps it and keeps track of where in the input bytes
each tag corresponds to.

Then using mark methods I can mark regions of the xml file for later
replacement.

I need the ability to mark regions in order to work backwards! But
with my
full blown parser (which I will not have ready before my vacation) you
just
cache all the events you might need to rewrite and then write them when
you
are ready.

At least this current solution works and I can _put out there_!

On Thu, Aug 14, 2008 at 3:14 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 14-Aug-08, at 6:24 AM, Stephen Connolly wrote:

The versions-maven-plugin is now rewriting XML correctly after some

hackery
with woodstox and string index tracking!

How close is this what we're looking for with rewriting XML properly?
Along
the lines of what we were talking about with Aaron. I would like to integrate something into what Shane is doing with StAX as a general
solution.

I would like to push a snapshot build for others to test (without
having
to
build from source)

Before I go doing something wrong.... what do I need to do and how do
I do
it!

-Stephen

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Three people can keep a secret provided two of them are dead.

-- Unknown


--- --- ---------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

-- Jacques Ellul, The Technological Society



--- ------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

-- Buddha


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to