Re: [vote] XML Parsing

[Aaron Mulder <am...@alumni.princeton.edu>]

	Well, in lieu of a vote, you have my moral support for the stated 
plan.

	If this plan is accepted, we should immediately establish the
naming convention and accessor convention (i.e. "enterprise-beans" tag
becomes EnterpriseBeans object and "session" tag becomes an (array)  
indexed property called "session" on the EnterpriseBeans object).

	Afterward, we should also agree on how XPath navigation should be
done.  Right now the JSR-88 code uses JDom, but it seems kind of wasteful
to load the same document twice (once into objects, once into JDom).  
Perhaps we should just agree to implement a limited XPath handler (it
could operate on our POJOs if the naming and accessors are consistent), or
to use the one in commons.  But I guess I'm getting ahead of myself.

Aaron

On Sun, 31 Aug 2003, Jeremy Boynes wrote:
> At this time I think the biggest issue is the lack of decision. None of
> the solutions seems, at this time, to be complete let alone perfect.
> XMLBeans appears to offer the most complete solution long term but does
> not seem to be ready now. Castor looks like a partial, short-term
> solution, but may not work long-term and may have licensing issues
> (Intalio).
> 
> I suggest the following plan:
> 
> * We define POJOs that represent the data objects but which are not
> bound to XML
>   or to any usage model (e.g. DConfig). This provides us with an object
> model
>   for the data everyone can use no matter which framework we end up
> using. A
>   requirement for the framework is that it can populate the data into
> and out
>   specializations of this object graph.
> 
> * Each tool that needs this data model can specialize the behaviour of
> this
>   object graph as needed - for example, DConfigBean impls might subclass
> these
>   object and add support for the DConfigBean interface and change
> notifications.
> 
> * We define a simple, loader framework that can load an XML instance
> document 
>   into this object graph. This is load only, so does not need to deal
> with any 
>   modifications to the graph. It does no validation over and above that
> supplied 
>   by the underlying parser. This should be kept really simple as the
> ultimate 
>   intention is to throw it away. How this is done is not yet known -
> digester
>   may be an option.
> 
> * We look for a framework that provides load and store functionality
> (including
>   schema validation of data during the store process) between XML
> instance
>   documents and the POJO object graph. The most likely candidate here is
> XMLBeans
>   as, eventually, it should be easy to modify it to get the exact
> behaviour we
>   need.
> 
> I would ask for a vote on this an an approach - please limit responses
> to +1, 0 or -1 and why (we have had enough discussion of alternatives
> for now).
> 
> --
> Jeremy
> 
> > -----Original Message-----
> > From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
> > Sent: Sunday, August 31, 2003 11:34 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: [XML Parsing]
> > 
> > 
> > On Sun, 31 Aug 2003, Jeremy Boynes wrote:
> > >...
> > > Where are we on XML parsing?
> > 
> > 	I'd like to resolve that too.  I've worked a bit with 
> > both Castor 
> > and XMLBeans on the deployment stuff, and here's what I've 
> > come up with:
> > 
> >  - Castor produces plain Java objects, with another layer of XML info 
> > objects that can be essentially ignored at runtime (they're used only 
> > under the covers)
> > 
> >  - XMLBeans produces richer objects, which know the name of 
> > the document they came from, support XPath queries, and so 
> > on, but also have a lot more in them than seems strictly 
> > necessary, and code is generated in at least one cryptic 
> > package other than the one(s) you're targeting.
> > 
> >  - Castor appears to depend on overriding the Xerces version 
> > in the JDK 
> > (for 1.4.2)
> > 
> >  - I can't get XMLBeans to actually load a document right now 
> > (due to some 
> > kind of missing file dependency?)
> > 
> >  - Castor has a smaller runtime library (over 1MB, but about 
> > 1/2 the size 
> > of XMLBeans)
> > 
> >  - XMLBeans is in the process of moving from BEA to Apache, 
> > but at last 
> > notice the source wasn't imported and the build script wasn't 
> > working.  On 
> > the other hand the current download from BEA appears to be 
> > covered by a 
> > BSD license.
> > 
> >  - reportedly Castor won't generate object for the full J2EE 
> > schema, while 
> > XMLBeans will, and JAXB will (painfully) [from James]
> > 
> >  - I know nothing else about JAXB
> > 
> >  - Castor is currently integrated into the build scripts (for 
> > Twiddle and the Geronimo EJB DD schema), while XMLBeans isn't 
> > quite (the code is there but the scripts need to be tweaked a bit)
> > 
> > 	I hope James will speak up, because I think he has more 
> > experience with JAXB and XMLBeans and the J2EE schema issue.  
> > I have a slight preference for Castor (since it and the beans 
> > it generates are both lighter weight), but I'm willing to go 
> > with XMLBeans if we can resolve the problem reading XML into 
> > objects and it's the only way to get the J2EE schema out (and 
> > the XPath feature seems likely to be pretty handy too).
> > 
> > 	Bottom line, I'd like to be able to just make a 
> > decision and move 
> > forward.
> > 
> > Aaron
> > 
> > 
> 

Re: [vote] XML Parsing

[Jan Bartel <ja...@mortbay.com>]

 >> On Sun, 31 Aug 2003, Jeremy Boynes wrote:
 >>I suggest the following plan:
 >>
 >>* We define POJOs that represent the data objects but which are not
 >>bound to XML
 >>  or to any usage model (e.g. DConfig). This provides us with an object
 >>model
 >>  for the data everyone can use no matter which framework we end up
 >>using.

+1




Aaron Mulder wrote:
> 	Afterward, we should also agree on how XPath navigation should be
> done.  Right now the JSR-88 code uses JDom, but it seems kind of wasteful
> to load the same document twice (once into objects, once into JDom).  
> Perhaps we should just agree to implement a limited XPath handler (it
> could operate on our POJOs if the naming and accessors are consistent), or
> to use the one in commons.  But I guess I'm getting ahead of myself.
This is a good issue to bring up - some code can be shielded from xml 
specifics, but in some cases dealing with objects rather than a document 
model is inconvenient (eg need to do xpath expressions).  So, it may not 
be appropriate for all code to use the POJOs. BTW: does anybody have any 
experience with the JXPath from commons that Aaron refers to? Is it fast?



Jan