[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    RE: default constructors
From:       "David Remy" <dremy () bea ! com>
Date:       2004-04-30 19:32:50
Message-ID: 4B2B4C417991364996F035E1EE39E2E10851BF () uskiex01 ! amer ! bea ! com
[Download RAW message or body]

> in V1.  Hence you were looking at a Lossy implementation.  Hence my
> follow-on questions earlier to Marshalling/Unmarshalling in V2.
> 
> Have things changed?

I think the emphasis in v2 on lossy, at least at this point, has changed.
right now in v2 you will see what is essentially a jax/rpc(++) binding that is
built on top of the xmlbeans schema compilation/schema object model.  when we started \
 the v2 work we were hoping that the jax-rpc binding (lossy) and the 
xmlbeans v1 binding (non-lossy) would play well together.  for example it would be \
cool  if you could start in non-lossy working with pojos, then perhaps find that you \
need a  feature in schema or in xmlinfoset that you need and just switch at compile \
or  runtime over to a different binding style.  it really has not turned out 
that way.  the jax/rpc binding style has turned out to be an orthogonal 
codebase from the xmlbeans binding style and the api and 
user model differs too much.  

i think it's best to think of xmlbeans as two major things, a schema \
compilation/schema  object model (bootstrapped by the xmlbeans binding), and the \
xmlbeans binding itself  which currently strives for 100% schema and 100% infoset \
fidelity (and results in certain archictural artifacts like XmlObject and the \
underlying xml store).  the SOM and the binding have different objectives.  The SOM \
provides a schema type system that can be leveraged for any XMLSchema based binding \
strategy.  The XMLBeans binding itself optimizes certain use cases and consequently \
makes some fundamental assumptions.  These use cases will continuously be expanded \
but in some circumstances the best strategy could be to build an entirely new binding \
leveraging the XMLBeans SOM.  

the jax/rpc binding in v2 is an example of building a binding on top of the XMLBeans \
SOM. the requirements for jax/rpc binding allow for a lossy, POJO type approach.  it \
is a great example of a legitimate situation for leveraging the XMLBeans SOM and \
establishing a new binding model.  the jax/rpc binding is not an inherent aspect of \
the xmlbeans it is one binding and has turned out to be more of a seperate binding \
project than we originally thought.  i  anticipate that work on the jax/rpc binding \
within the xmlbeans project will subside or move to a different project.  

we have heard that other projects have considered taking advantage of the xmlbeans \
SOM so one thing i anticipate more of in v2 is making sure that the SOM is cleanly \
pluggable.

in v2 xmlbeans binding we will continue to address the new uses cases that we (apache \
dev community) have been discussing.  fundamentally i believe that 100% schema \
support and 100% infoset are critical constraints/guidelines to consider with new \
features.  IMO, it's  fundamental to xmlbeans that it is about leveraging the full \
power of xml in java.  this is important in a general xml/java solution (like one \
that would be adopted as an standard for an entire enterprise) since it means that \
ultimately you may not be in control of the schemas that you are working with and the \
shape or content of the xml that you have in hand.  yes, a  less xml complete \
solution might allow you use the schemas or process the xml instances that you have \
laying around now, but what about the 'next' schema/xml?  wouldn't you want to invest \
in a binding strategy that you can be assured will meet all of the situations you are \
likely to encounter in xml?

i certainly understand that there are situations, like for example when you simply \
using xml as a transport for relational data, where schema and xml infoset complexity \
is constrained, that the xmlbeans binding could be sub-optimal - at least as it is \
implemented now.  perhaps another,  simplified binding strategy would work better in \
that scenario.  

that being said i think, given the foundation that has been built, we can attack the \
more constrained use cases within the xmlbeans binding itself (as opposed to spawning \
another binding from the SOM).  for example, it is possible to imagine an 'infoset \
lossy' setting at codegen  time that would generate a java class based implementation \
of the XMLObject interface in the  generated classes.  Factory.parse() would directly \
populate java objects (hence parts of XML Infoset would not be available), calls to \
APIs that give direct access to the xml store, like newCursor(), would get an \
UnsupportedOperationException.  The key here is that a user should be  able to flip \
that codegen/compilation switch at any point if they determine they need access to \
more of the underlying XML Infoset and not break any of their existing code.

one area of change that i don't see even a hypothetical approach for yet is \
generating POJO from the SOM.  The underlying programming model (the user code) is \
fundamentally affected by having the methods shaped by XmlObject in particular the \
premise that the java type hierarchy must match the schema type hierarchy.  much of \
xmlbeans ability to handle all types of schema (in particular type substitution) is \
from the matching XML Schema and XMLObject hierarchy that is represented by the  \
generated classes that implement XmlObject.  i suspect that much of the situations \
where people ask for POJO that they want 1) to extend their class in some way - which \
we can address by the  extension mechanisms (early bits recently checked in by cezar) \
or 2) to take advantage of tooling that want 'javabean' type functionality - this is \
thornier but i believe can be addressed with some creativity (some ideas are starting \
to pop up).  

an implication of not having pojos is that two similar usage scenarios are hard.  \
One, start from java. Two, start from both (mapping existing xml schema to existing \
java classes).  The reason I hear often about the need for start from java is that \
java developers do not know  xml schema well and sometimes (web services is probably \
most common scenario for this) they would like  to just create their java data \
structures and have schema pop out.  This is surely an  important scenario that \
xmlbeans does not work that great for right now.  i can't imagine devs  writing \
native xmlobject derived classes that look like the ones we generate in order to get \
a schema :)  open to suggestions here, one idea i have heard but is a little strange, \
is to have a java to schema compilation that would take in a POJO, generate an  \
XmlObject derived interface/impl, generate an XML Schema from that, and essentially \
discard the POJO. Seems fraught with problems.  For now, XMLBeans is schema to java \
based until we figure out how how to deal with this.

In the case of 'start from both' what seems to be the real requirement is \
'transformation' which can be accomplished by writing a simple mapping java class \
that reads the xml via the generated classes and then creates the existing classes \
that are needed.  this could be done via xquery as well once we determine how to hook \
up an open source xquery engine into xmlbeans.  bea uses tooling on top of \
xmlbeans/xquery to allow a user to map from a schema to a java class (or schema to \
schema).  it works well.  maybe there is some start from both use case i don't \
understand but it doesn't seem like a major feature area for xmbleans in the near \
term.

Sorry for such a long post on this, just started dumping ...

> 
> This is still very interesting to me.
> 
> - Brian
> 
> "David Remy" <dremy@bea.com> wrote on 04/26/2004 02:47:57 PM:
> 
> > Eric Vasilik wrote:
> > > Something to keep in mind here is that XmlBeans are not classes,
> > > they are interfaces.  We do generate implementations for these
> > > interfaces, but the "blessed" way to construct an XmlBeans is via
> > > the Factory methods, like FooDocument.Factory.newInstance(), or the
> > > parse methods. These implementations are private to XmlBeans and
> > > subject to change. They should not be accessed directly by users.
> > > 
> > > The design goal of XmlBeans was to create a set of Java interfaces
> > > which could be used to access/modify/construct XML as defined by W3C
> > > XmlSchema.  In effect, these interfaces are "portals" to the XML,
> > > they are not meant to *be* the XML (element, attr, etc).  In
> > > XmlBeans, the actual XML is not stored in the XmlObject, but is
> > > stored elsewhere. XmlObject, and all the generated interfaces, are
> > > created on demand as the user peruses the XML, or changes the
> > > schema type 
> > > associated with he
> > > XML.  It is the XmlObject which gives typed access to the XML.
> > > 
> > > Also, consider the pattern one would use if there were,
> > > somehow, default
> > > constructors (lets say there is a foo element which can contain a
> > > bar element, which can contain an integer baz element):
> > > 
> > > Bar bar = new Bar();
> > > Bar.setBaz( 123 );
> > > 
> > > Foo foo = new Foo();
> > > Foo.setBar( bar );
> > 
> > this is equivalent in xmlbeans to doing:
> > Bar bar = Bar.Factory.newInstance();
> > bar.setBaz( 123 );
> > 
> > Foo foo = Foo.Factory.newInstance();
> > foo.setBar( bar );
> > 
> > so it is possible to build an xmlbean from the 'bottom' up.
> however, it
> will
> > be the least efficient way to do it since every time you do a
> > newInstance an xmlfragment is created to hold it in the underlying
> > xml store (as explained below). 
> > 
> > > 
> > > Now, when the setBar executes, the semantics of XmlBeans is to
> > > *copy* the XML for bar and set the value of foo to be that copy.
> > > Which means that the following: 
> > > 
> > > Bar bar2 = foo.getBar();
> > > 
> > > Will return a bar2 which is != to bar.  This kind of construction is
> > > very inefficient in XmlBeans (because of the copies).  The
> > > 'XmlBeans-correct' way to perform this construction is:
> > > 
> > > Foo foo = Foo.Factory.newIntance();
> > > Bar bar = Foo.newBar();
> > > Bar.setBaz( 123 );
> > > 
> > > This is a 'top-down' construction method.  No superfluous copies are
> > > made.  In effect, new objects are not explicitly constructed and
> > > then added, they are implicitly constructed as they are added.
> > > 
> > > What I'm trying to show here with these examples (there are other
> > > similar issues) is that the idea of adding default constructors (or
> > > constructors of any kind, for that matter) goes against the
> > > grain of the
> > > design goals for XmlBeans.
> > 
> > i am not sure that it is the constructors themselves that are going
> > against the design grain of xmlbeans.  the default constructor on
> the impl would
> be
> > analogous to the Factory.newInstance() on the interface.
> however, 1) it
> is
> > weird to have the default constructor on an impl that is
> normally behind
> an
> > interface.  perhaps we should revisit in V2 why we are
> using interfaces
> at
> > all for generated classes.  2) use of the default
> constructors, which
> would
> > be the most natural way to build up an xmlbean by a java developer
> > using java objects might lead xmlbeans users down an in-efficient
> > pattern of building up xmlbeans.
> > 
> > this seems to primarily about a design trade-off between
> > do-ability.i.e., is it *doable* to have a default constructor that
> > can behave as a javabean for tools using runtime reflection?  which,
> > i *think* default 
> constructors are
> doable.
> > And performance/scaling, i.e, is it possible to default constructors
> > that result in high performance and scalabliity.  which i *think*
> > the answer is probably no, since when using a typical java 'bottom
> > up' contruction 
> pattern we will
> be in
> > pure copy scenarios where we do copies and then leave lots
> of objects
> hanging
> > around for collection.
> > 
> > we should think about this feature more.  i have heard this
> issue come
> up the
> > most around hibernate.  it seems like hibernate would have
> or should
> have a
> > more flexible persistence mechanism than relying
> exclusively on using
> javabean
> > introspection.  if it has a plug-in serializer model of some sort
> > then it seems like it would be straightforward to provide an
> > optimized serializer/deserializer that would take the 'top down'
> > approach that xmlbeans optimizes. 
> > 
> > i am also concerned about the overall javabeans/xmlbeans
> compatibility.
> it
> > seems compelling to have xmlbeans as javabeans compliant as
> possibleto
> open it
> > up to working with javabeans tooling.  hibernate is an
> example of this
> but i
> > assume there are many other similar tools.
> > 
> > 
> > > 
> > > It looks like the Hibernate technology wants to construct the java
> > > objects piecemeal, and then glue them together, potentially in a
> > > 'bottom-up' manner, while XmlBeans want to construct a document in
> > > a 'top-down' manner. 
> > > 
> > > Without a significant architectural re-visit of Xmlbeans, adding
> > > this kind of functionality may not be possible.
> > > 
> > > Comments?
> > > 
> > > - Eric
> > > 
> > > -----Original Message-----
> > > From: Javier Ramos [mailto:ramos@parsec.es]
> > > Sent: Monday, April 26, 2004 1:38 AM
> > > To: xmlbeans-user@xml.apache.org
> > > Subject: Re: default constructors
> > > 
> > > Hi
> > > 
> > > I have developed a web application framework for my company use,
> > > following MVC pattern ( you might think I am crazy, but I did not
> > > find ot there what I want ). There is one presenation server,
> > > receiving XML data to
> > > generate possibly multiple user interfaces and documents with Cocoon
> > > XSLT, HSSF, PDF... transformers, communicating via HTTP with and a
> > > controller + business logic server in which the model uses the
> > > Hibernate ORM. 
> > > 
> > > We have to define the schemas for the application requests and
> > > responses, and XMLBeans generates for us the java code that helps us
> > > get/set the information for requests/responses in the controllers
> > > using java, and allows to serialize/deserialize them to the HTTP
> > > input/output streams. 
> > > 
> > > Currently I need to deal with objects to carry request/responses
> > > (although the code is generated for me), and model objects
> > > that most of
> > > the
> > > time just copy the information from/to the properties of the
> > > request/response objects. Response objects normally just reflect the
> > > state in a given moment of time of some of the model components.
> > > 
> > > If XMLObjects could be persisted with Hibernate, maybe I could
> > > think of
> > > saving steps, making some unification between response
> > > objects and model
> > > objects. I still need requests to be different objects, but
> > > responses are mainly reflecting the state of some model objects, so
> > > both concepts (response + model) could be somehow merged into items
> > > that can be both serialized/deserialized from XML AND persisted
> > > with Hibernate, AND given some additional business logic methods
> > > (which of course the schema compiler should leave untouched ).
> > > 
> > > So I find this request to combine Hibernate + XMLBeans VERY
> > > interesting. I would like to ask if there is the possibility to add
> > > business logic methods to the XMLBeans generated classses in such a
> > > way that a recompilation of the schemas will not wipe out the added
> > > code. 
> > > 
> > > Also maybe someone will tell me that what I am trying to do is
> > > already done by someone else and I can forget about this huge
> > > (although interesting) task I am embarked in.
> > > 
> > > Best regards,
> > > 
> > > Javier Ramos
> > > 
> > > 
> > > ----- Original Message -----
> > > From: "nn" <nnakae@comcast.net>
> > > To: <xmlbeans-user@xml.apache.org>
> > > Sent: Saturday, April 24, 2004 12:21 AM
> > > Subject: Re: default constructors
> > > 
> > > 
> > > > Hi,
> > > > If XMLBeans generated classes can be persisted by Hibernate(Right
> > > > now because lack of defualt constructor, this seems not possible),
> > > > The hibernate map file *.hbm.xml files for the XMLBeans generated
> > > > classes should be generated directly  from *.xsd file.
> > > > This would be very powerful tool.
> > > > Are there any such idea pursued in this project?
> > > > 
> > > > nn
> > > > 
> > > > ----- Original Message -----
> > > > From: "David Remy" <dremy@bea.com>
> > > > To: <xmlbeans-user@xml.apache.org>
> > > > Sent: Friday, April 23, 2004 2:37 PM
> > > > Subject: RE: default constructors
> > > > 
> > > > 
> > > > Dmitri.Colebatch@toyota.com.au wrote:
> > > > > hey all,
> > > > > 
> > > > > I'm wondering if anyone had any thoughts progress on the lack of
> > > > > default constructors for xmlbean generated classes (see
> > > > > http://nagoya.apache.org/eyebrowse/ReadMsg?listName=xmlbeans-u
> > > > > ser@xml.apache.org&msgNo=369).
> > > > > 
> > > > > in short, I'd like the XMLBeans generated classes to have default
> > > > > constructors.
> > > > 
> > > > hey dim.  do you think if we put a default contructor on
> > > the impl that
> > > it
> > > > would meet your needs?  this isn't for a user it is for tooling
> > > > (like hibernate), right?  i don't see why we could not generate a
> > > > default constructor on the impl and tools that do introspection
> > > > for a default contructor would work.  that seems very valuable
> > > > since that is one thing that currently makes xmlbeans not meet the
> > > > javabean 
> > > criteria.  i think
> > > it
> > > > would really increase the tooling accessibility.
> > > > 
> > > > am i missing something anyone?  is there a reason why we should not
> > > > put a default constructor on the codegenned xmlbean impls?
> > > > 
> > > > rem
> > > > 
> > > > > 
> > > > > cheers
> > > > > dim
> > > > > 
> > > > > 
> > > > > -
> > > > > 
> [snip/]
> 
> 
> -
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


[prev in list] [next in list] [prev in thread] [next in thread]