xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bau" <david...@hotmail.com>
Subject Re: granularity of binding selection [Re: Status of Marshalling/Unmarshalling in V2? Javadoc?]
Date Mon, 01 Mar 2004 15:08:39 GMT
> 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.

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).

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.

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

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.

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

(IMO only...)

David


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