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

List:       xmlbeans-dev
Subject:    granularity of binding selection [Re: Status of Marshalling/Unmarshalling
From:       Aleksander Slominski <aslom () cs ! indiana ! edu>
Date:       2004-02-28 22:44:17
Message-ID: 404119C1.8070907 () cs ! indiana ! edu
[Download RAW message or body]

David Remy wrote:

> XML Schema Support ----------->
> Inherits from:
> Object	  ||	XmlObject
> (unboxed)   ||    (boxed)
> ^       |------------------------------
> > > xmlbeans     ||
> > > pojo         ||  xmlbeans
> > > lossless     ||  'classic'
> > > (Not impl V2) ||
> > > --------------||----------
> > > xmlbeans      ||  xmlbeans 
> XML      |  pojo         ||  xmlobject
> Infoset  | (e.g. JAX/RPC)||  only
> Fidelity |               || (Not impl V2)
> ------------------------------
> 
> there needs to be whole paper written on this grid (also the names for each of \
> these quadrants needs work).  the left side represents pojo, and inherit from \
> java.lang.Object.  the right side represents high schema compliance and inherits \
> from XmlObject, critical for supporting 100% schema.  the boundary between the left \
> and right side is a double line because it will be a pretty big hurdle to move \
> between the left and the right side.  a simple compilation switch will not do it \
> since the classes themselves and the api have tight coupling with their ancestral \
> parent (object or xmlobject).  however it should be possible to move up on the same \
> side with a simple compilation switch.   
> 
hi David,

did you consider a case when different parts of XML stream (document) 
may be bound using different techniques? including case when parts of 
XML are not bound at all i.e. event stream is available for direct 
consumption in processing pipeline?

> the bottom left is one of the major objectives for v2 to support a non-lossy use \
> case for java-xml binding and will definitely be done for v2.  the upper right is \
> basically xmlbeans v1 plus some improvements for v2.  the bottom right is a very \
> interesting case that would great to have for v2 but isn't yet in plan.  the idea \
> there is that you should be able to use the high schema compliance xmlobject path \
> but not necessary incur the overhead of having both an xmlstore and an xmlobject \
> layer.  if you don't need full infoset fidelity and access to the underlying \
> xmlstore you should be able to compile with 'xmlobject only', lacking a better name \
> for it, and get all of the schema compliance.  at parse time the java objects are \
> created and populated directly on unmarshal.  if you find you need access to the \
> full infoset later you can just flick a compile switch, 'non-lossy' or 'full \
> fidelity' (again naming issues), and all of your existing code will just work plus \
> you can use xmlcursor to get to the xmlstore.  this is probably 80% or higher of \
> the current usage for xmlbeans so we shoud scope this out better and implement it.  \
>  
typical case i think about is SOAP message that is framed into SAAJ/DOM 
(or any other DOM-like or XML Infoset API) and SOAP headers are bound 
using xmlbeans 'classic' or xmlbeans pojo but SOAP body content if it is 
not Fault is left untouched as XML event stream (implemented with 
streamable xmlstore that has StAX interface)? that XML event stream 
could be bound to XML beans or used to build SAAJ/DOM but decision is 
left to the application and it would allow to write processors that can 
handle very large messages (streaming) but still reap benefits of Java 
types generated from XML schema if they need to bind some parts of event 
stream ...

i played with such approach in XPP2 unfortunately i made API way too low 
level. the idea is that XML element can be in two states:
* expanded: underlying stream representing element content was fully 
processed
* non-expanded: in this case XML stream is currently pointing at this 
element and instead of creating XML children user can access event 
stream to pull events
for more details 
http://www.extreme.indiana.edu/xgws/xsoap/xpp/download/PullParser2/doc/api/org/gjt/xpp/XmlPullNode.html


i think i can use easily enough xmlbeans v1 to bind any sub-stream that 
represents subtree of XML (everything between start tag and its 
corresponding end tag) but there is no control available to tell 
xmlbeans to defer binding any sub-sub-stream content?

> the other case represented in the grid is the top left, 'lossless pojo" scenario.  \
> this isn't as intiutive but we have run across scenarios where this has been \
> requested (fervently).  for example if the lower left quadrant was needed for \
> runtime cases but the desire to keep infoset fidelity (like preserve comments) at \
> design time was required.  we have emailed/white boarded some strategies awhile \
> back for this (not on apache dev) which involved a 'best effort' fidelity scenario \
> which essentially involved mapping nodes to the created pojo objects such that at \
> marshal time, with some pretty significant constraints, the infoset could be \
> preserved. 
> 
the last question: will it be possible to rebind parts of xmlstore with 
different schema impl. i.e would i be able in xmlbeans v2 to switch 
parts of XML from xmlbeans to pojo (and vice versa) or even have then 
all as simultaneous views  (xmlstore + pojo + xmlbeans) and XML editing 
changes to be reflected in each view?

it seems to me that if carefully designed it should be possible to have 
nice infoset API (xmlstore, StAX) and schema binding (XmlBeans pojos and 
XmlObject) and still expose to advanced users XML stream for maximum 
performance.

i am very interested to hear your opinion about those issues.

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay


- ---------------------------------------------------------------------
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]