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]
