xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: granularity of binding selection [Re: Status of Marshalling/Unmarshalling in V2? Javadoc?]
Date Tue, 02 Mar 2004 01:28:07 GMT
David Bau wrote:

>>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?
>>    
>>
>
>Can't speak for remy, but I know the main interesting thing
>about v2 is to try to figure out how to apply different
>binding styles at once.  You want to either be able to bind
>in XmlObject style, plain POJO style, or perhaps not bind at
>all and leave it as a DOM.  Ideally, you can nest one within
>the other and vice-versa.
>  
>
yes. i think nesting is a powerful concept allowing for freedom to treat 
XML any way you need at the given moment.

>But the dichotomy between bringing the data into memory and
>letting it stream is different from binding or not-binding.
>The reason?  Streaming and in-memory are two different API
>approaches.  If you try to intermix them, then in the common
>case, you end up forcing everything into memory anyway
>(e.g., if somebody asks for "the last parameter" to be bound
>to "the last element" as a POJO, while the "first parameter"
>is left as a stream...  To actually supply the last
>parameter, you need to read the whole stream into memory
>anyway; at which point, the user might as well also have the
>ability to get a DOM).
>  
>
there is always edge case like that however i can also see usefulness of 
reading XML and allowing user to discard parts that are no longer needed 
something similar to a typical loop that reads list of entries from XML 
stream. the stream may not fit into memory but at any given time user 
needs to see only small part of it (with some context).

>So for the question of streaming versus in-memory, I feel
>like the right solution is not to treat them as peers, but
>to let them layer on top of one another.  You should be able
>to provide an in-memory model by binding on top of a stream.
>Or you should be able to get a stream from an in-memory
>model.
>  
>
they will have to be layered but the question is how to get from higher 
level layers (DOM, XmlObject) to underlying stream layers (StAX, token 
stream, byte 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?
>>    
>>
>
>XMLBeans v1 never defers _loading_ the XML tokens into
>memory.  It might make an interesting project for somebody
>to see if loading can be made "incremental" so it's only
>done on-demand, but XMLBeans v1 always exhausts the stream
>to the end right now.
>  
>
i think that is interesting in context of trying to make XmlBeans to 
work with large inputs *and* to provide easy to use high level API like 
DOM / XmlObject.

>However, XMLBeans v1 always defers _binding_ the XML into
>Java object until the moment when you call the getter to
>access the particular part of the tree.  When you load, what
>you load is the raw XML infoset tokens, as quickly as
>possible.  The XmlObject objects don't come into existence
>until later.  In fact, we're missing an option to request
>all the binding be done up front; we always do it lazily.
>  
>
that sounds good.

>>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?
>>    
>>
>
>There are technical challenges in presenting a truly pojo
>view at the same time as synchronizing editing changes.  A
>true pojo is "just the user's code", and the user doesn't
>need to tell us what they've done within a setFoo() method.
>
>I don't think anything technical prevents the three views
>from being presented simultanesouly for read-only use, or
>for xmlbeans+xmlstore from being consistent on writes.
>
>However, it does seems like a usability question.  Looking
>at the way most people use binding, they expect a _single_
>early-bound Java class to be bound to a schema type and are
>suprised if there is more than one.
>
>I'd suggest that:
>
>(1) There should be two bindings for each built-in schema
>type (i.e., xsd:string -> XmlString as well as
>java.lang.STring)
>(2) But for user-defined schema types, we should probably
>design the tools to either require or encourage that there
>be only one binding, or at least that one of them is
>"primary".
>
>(2) Purely seems like a usability question to me, though.
>
>  
>
so here is really the question whether to maintain replicated data (xml 
token, XmlObject, XML Bean, pojo have their own copy) or have them to  
access one shared  data  (XML Infoset directly).

>(IMO only...)
>
>  
>
thanks for info!

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/


Mime
View raw message