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]
