Re: [Classpathx-xml] gnujaxp with JDK1.1.8

[David Brownell]

Remember that AElfred2 is just the SAX parser ... you're talking
about it as if it's the whole GNUJAXP package!

Will you provide patches for any of this configuration hacking?
Seems like autoconf options would be the way to go.

Also, I'm still unclear what you're after.  Since you have the source
code and are already linking a custom/embedded configuration,
most of these are just "use a different Makefile" type issues.

- Dave

p.s. Removing the "instanceof" is orthogonal to creating a
    non-validating configuration, so your (1) below is two very
    different issues.


----- Original Message ----- 
From: "Ma, Steve" <address@hidden>
To: "'David Brownell'" <address@hidden>
Cc: <address@hidden>
Sent: Tuesday, December 11, 2001 11:43 AM
Subject: RE: [Classpathx-xml] gnujaxp with JDK1.1.8


> After collecting some opinions from the members on my team who will also be
> working with the XML parser, we think it would be best if Aelfred2 was to
> offer the following solution:
> 
> 1) Offer the capability to make a package that as a non-validating jaxp 1.1
> parser.  That would include removing the instanceof in bind() so that you
> wouldn't need to include a lot of helper classes.
> 
> 2) Remove DOM from the package.  That would allow you to use this JAXP1.1
> parser in any DOM implementation.  We have our own DOM implementation with
> PDOM and don't need theirs.
> 
> 3) Able to use Aelfred's SAX2 parser directly should be easy.  I hope that
> we can get pdom folks to allow us to plug in sax2 instead of jaxp.
> 
> Thanks,
> Steve
> 
> -----Original Message-----
> From: David Brownell [mailto:address@hidden 
> Sent: Monday, December 10, 2001 3:40 PM
> To: Ma, Steve
> Cc: address@hidden
> Subject: Re: [Classpathx-xml] gnujaxp with JDK1.1.8
> 
> > However, in order for this Aelfred2 to be JAXP1.1 compatible, we need to
> > include the JAXPFactory, which in turn uses XmlReader, 
> 
> If you're concerned about space, consider dropping JAXP and using
> SAX directly.   JAXP adds most of the dependencies on "optional"
> pJava capabilities, like java.io.File support, and supporting DOM
> (and TRAX) costs a bunch too.  And it's not like you'd be using APIs
> that aren't portable!
> 
> Or consider tweaking JAXPFactory so that it returns a SAXDriver not
> an XMLReader, unless you need validation inside that PDA code.
> (Do you really need validation there?)
> 
> 
> >    and XmlReader needs
> > pipeline support.  And the chain goes on to include the util directory.
> 
> Actually, XMLReader only needs two pipeline classes, and that's
> only to use validation.  (And EventConsumer, an interface.)
> 
> The problem is that EventFilter holds bind(), which knows about
> a couple other classes:  NSFilter, ValidationConsumer, and
> WellFormednessFilter functionality for functions that can sometimes
> be turned into XMLReader feature flags; and XIncludeFilter (one of
> a few classes that expects some other flag settings), which also
> touches the Resolver class (has a JDK 1.1 File.toURL analogue).
> 
> I suppose I could teach bind() to use class operations rather than
> use "instanceof", that'd make it easier for folk like you to just remove
> classes to get a smaller jarfile that still supports validation.
> 
> 
> > I understand maintaining multiple configuration/distribution is
> troublesome,
> > so I'd rather not trouble you for the maintenance except I'd prefer not
> > modifying any source code because it will make it harder to upgrade.  
> 
> I want to know how to make it easier for you to use this software
> through upgrades, too!  :)
> 
> 
> > Is there a way to make the jar lighter at the same time keeping it JAXP1.1
> > compatible? 
> 
> See above.  Do you need DOM?  If not, I'm not sure there's a good
> reason to use JAXP, and that saves a big chunk right off.
> 
> If you don't need the validation support, but do need JAXP, I've thought
> that it'd be simple enough to automate applying a patch during the build
> to change the compiled-in defaults.  Useful for me to have that for SAX
> (I've got to patch XMLReaderFactory by hand), and potentially for you to
> make JAXPFactory use the non-validating parser.
> 
> Otherwise it seems like the main issue would be teaching bind() not
> to use "instanceof", so you could validate but not link so much in.  If
> you need that, it could get into a beta2 relase (let me know soonish).
> 
> - Dave
> 
> 
> 
> > Thanks,
> > 
> > Steve
> > 
> > -----Original Message-----
> > From: David Brownell [mailto:address@hidden 
> > Sent: Friday, December 07, 2001 8:21 PM
> > To: Ma, Steve
> > Cc: address@hidden
> > Subject: Re: [Classpathx-xml] gnujaxp with JDK1.1.8
> > 
> > > Is it possible to release just the AElfred2 parser alone in a jar to
> > > minimize the size? 
> > 
> > Why don't you just assemble a jarfile with the relevant SAX
> > code and these two classes?
> > 
> >     - gnu.xml.aelfred2.SAXDriver
> >     - gnu.xml.aelfred2.XmlParser (internal class)
> > 
> > That won't include the validation support, but that's the core
> > of AElfred2.   It's only the _optional_ validation support that
> > brings in any of the pipeline support, and that shouldn't require
> > that whole package, or anything in "util".  (If it does, please
> > submit an appropriate patch!)
> > 
> > The deal is that I don't want to get into the business of
> > trying to maintain multiple configurations/distributions.
> > Anyone with access to the source code can arrange the
> > linking to their convenience. Or heck, even with just the
> > jarfile ... :)
> > 
> > - Dave
> > 
> > 
> 
> _______________________________________________
> Classpathx-xml mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpathx-xml