You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/10/20 07:24:36 UTC
[Axis2] OM API review/changes
hi,
it seems that we are converging on OM API so i did review of current OM API and committed to SVN an
updated version.
as i reviewed existing OM APIs and worked on modifications i concentrated on making API more
lightweight. in particular to allow String to be direct child of OMElement and to have as many as
possible immutable objects in API (such as attributes, namespaces, ...)
the biggest difference is that i removed OMNode as there is no one superclass for all XML Information
Items and this allows to store String *directly* as child of OMElement.
when DOM API wrapper is done over OM API it will have to use Node super interface but i wanted to defer
it to situations only when DOM API is requested by some handler. so there may be still some changes
depending on how much of DOM API we implement ...
the issue that is not clear to me is how OM API can be used to access event stream for SOAP:Body
content (and avoid building OM elements for its content) - how isComplete() method should be used in
this context?
for more details see:
https://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/alek/axiom/
https://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/alek/axiom/infoset_api/org/apache/axis/om/
and
http://wiki.apache.org/ws/FrontPage/Architecture/OM
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: use of immutable value object/interfaces [Re: [Axis2] OM API
review/changes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Ajith Ranabahu wrote:
>Hi,
>How I see this mutable/immutable thing is this.
>If we make an object immutable we are done with making changes to it.
>The only option we have if we are not happy with the values that are
>inside the immutable object is to make a new one with the correct
>values and replace the earlier one.
>
>
that is correct.
>As far as an XML document structure is concerned, having to create a
>whole new element when a change is needed seems ridiculous (since it
>is quite frequent).
>
i agree :)
>by contrast namespaces stay unchanged through the
>scope of the document and are good candidates for being immutable
>objects.
>
>
yes
>Hopefully this is the essence of the concept of mutable/immutable.
>Please correct me if I am wrong.
>
>
sounds correct to me.
>When our OM is concerned, I tend to put only OMNamespace as immutable.
>An attribute doesn't seems to be that much convincing as an immutable
>object to me.
>
>
i have just searched heavy XML message/XML schemas/WSDL manipulating
code (Xydra
<http://www.extreme.indiana.edu/viewcvs/%7Echeckout%7E/mgc/xydra/>) and
did not find *any* example where attribute value were changed instead
most code was about finding attributes/values and adding new attributes ...
alek
>
>
>>On Fri, 22 Oct 2004 09:27:24 +0600, Eran Chinthaka
>><ch...@opensource.lk> wrote:
>>
>>
>>
>>Alek's idea of making OMElement mutable and others immutable seems
>>interesting.
>>
>>
>>
>>Shall we talk about this in use cases perpectives ???
>>
>>
>>
>>What are the things we do for the soap message within the engine ??
>>
>>
>>
>>1. need to access the headers. What we basically do here is that mostly
>>read the contents of the headers. And sometime may remove and add new
>>headers. Plus we may modify Element, Texts, Attributes. But I think we
>>rarely do modifications to comments or namespaces. In this regard, making
>>OMElement mutable make sense, but I would say that Attributes are highly
>>subjected to modifications. So making OMAttributes also mutable seems good.
>>But I agree in making rest of the things immutable.
>>
>>2. If u think about the body, in current situations this will be accessed
>>only by either Security handlers or by the provider. (If this is not
>>correct, I like to see a *use case*, where someone need to access the body).
>>Provider of course, it needs to just read the contents of the body. SO there
>>are no modifications to the body.
>>
>>As Sanjiva said, we can forget the performance discussion about the
>>supporting of security.
>>
>>
>>
>>So in conclusion, I think following seems to be ok, for the time being.
>>
>>
>>
>>OMElement, OMAttribute – mutable
>>
>>OMNamespace, OMText (or String) – immutable.
>>
>>
>>
>>Plus I also agree with the idea of "to allow use of immutable objects that
>>can be shared (such as the same namespace) between multiple elements leading
>>to lower memory usage."
>>
>>
>>
>>
>>
>>Comments …………… ?
>>
>>
>>
>>________________________________
>>
>>
>>
>>Eran Chinthaka
>>
>>Lanka Software Foundation
>>
>>
>>
>>
>>
>>
>>
>>>-----Original Message-----
>>>
>>>
>>>From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>>>
>>>
>>>Sent: Friday, October 22, 2004 6:15 AM
>>>
>>>
>>>To: axis-dev@ws.apache.org
>>>
>>>
>>>Cc: chintaka@opensource.lk
>>>
>>>
>>>Subject: use of immutable value object/interfaces [Re: [Axis2] OM API
>>>
>>>
>>>review/changes
>>>
>>>
>>>Sanjiva Weerawarana wrote:
>>>
>>>
>>>>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>>>>
>>>>
>>>>>i agree that API should be easy to use but we need to strive for a
>>>>>
>>>>>
>>>>>balance and be careful to have necessary methods to make API easy to
>>>>>
>>>>>
>>>>>use (but not too many) and to allow use of immutable objects that can
>>>>>
>>>>>
>>>>>be shared (such as the same namespace) between multiple elements leading
>>>>>
>>>>>
>>>>>to lower memory usage.
>>>>>
>>>>>
>>>>I'm confused .. we obviously need to create the OM too. Are we
>>>>
>>>>
>>>>talking about disallowing one to *modify* an already created tree
>>>>
>>>>
>>>>instead of about having methods to create a new OM?
>>>>
>>>>
>>>no that is nto what i meant.
>>>
>>>
>>>i though about case of tree (OMElement) that is container of objects
>>>
>>>
>>>where some of those objects are immutable (like namespaces or attributes).
>>>
>>>
>>>so if you need to change element namespace or attribute just create new
>>>
>>>
>>>one and replace element namespace or attribute.
>>>
>>>
>>>exactly the same reasoning goes for immutability of String (including
>>>
>>>
>>>multi-thread safety for sharing, caching, low memory usage etc.) and for
>>>
>>>
>>>more detailed rationale for immutable "value" object please read (better
>>>
>>>
>>>explained that i can):
>>>
>>>
>>>http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>>>
>>>
>>>>If so I'm ok with having the OM be immutable at least initially.
>>>>
>>>>
>>>i was not proposing anyting that radical - i think OMElement should be
>>>
>>>
>>>mutable only OMNamespace, OMAttribute should be immutable (and maybe
>>>
>>>
>>>OMComment).
>>>
>>>
>>>>That should give us maximum performance and if you really want
>>>>
>>>>
>>>>to modify the OM then you have to re-generate it. That may bite
>>>>
>>>>
>>>>us badly when dealing with encrypted headers but we can delay
>>>>
>>>>
>>>>that a bit I think. (Decryption will be so slow that creating
>>>>
>>>>
>>>>a new OM will not be a problem :)) However, we should be able
>>>>
>>>>
>>>>to re-parent OM nodes I think.
>>>>
>>>>
>>>that would be interesting: to have read-only API, copy-on-write API and
>>>
>>>
>>>full read-write API subsets that are selectable as required by and
>>>
>>>
>>>described in metadata of handlers ...
>>>
>>>
>>>thanks,
>>>
>>>
>>>alek
>>>
>>>
>>>--
>>>
>>>
>>>The best way to predict the future is to invent it - Alan Kay
>>>
>>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
How I see this mutable/immutable thing is this.
If we make an object immutable we are done with making changes to it.
The only option we have if we are not happy with the values that are
inside the immutable object is to make a new one with the correct
values and replace the earlier one.
As far as an XML document structure is concerned, having to create a
whole new element when a change is needed seems ridiculous (since it
is quite frequent). by contrast namespaces stay unchanged through the
scope of the document and are good candidates for being immutable
objects.
Hopefully this is the essence of the concept of mutable/immutable.
Please correct me if I am wrong.
When our OM is concerned, I tend to put only OMNamespace as immutable.
An attribute doesn't seems to be that much convincing as an immutable
object to me.
Ajith
>On Fri, 22 Oct 2004 09:27:24 +0600, Eran Chinthaka
><ch...@opensource.lk> wrote:
>
>
>
> Alek's idea of making OMElement mutable and others immutable seems
> interesting.
>
>
>
> Shall we talk about this in use cases perpectives ???
>
>
>
> What are the things we do for the soap message within the engine ??
>
>
>
> 1. need to access the headers. What we basically do here is that mostly
> read the contents of the headers. And sometime may remove and add new
> headers. Plus we may modify Element, Texts, Attributes. But I think we
> rarely do modifications to comments or namespaces. In this regard, making
> OMElement mutable make sense, but I would say that Attributes are highly
> subjected to modifications. So making OMAttributes also mutable seems good.
> But I agree in making rest of the things immutable.
>
> 2. If u think about the body, in current situations this will be accessed
> only by either Security handlers or by the provider. (If this is not
> correct, I like to see a *use case*, where someone need to access the body).
> Provider of course, it needs to just read the contents of the body. SO there
> are no modifications to the body.
>
> As Sanjiva said, we can forget the performance discussion about the
> supporting of security.
>
>
>
> So in conclusion, I think following seems to be ok, for the time being.
>
>
>
> OMElement, OMAttribute – mutable
>
> OMNamespace, OMText (or String) – immutable.
>
>
>
> Plus I also agree with the idea of "to allow use of immutable objects that
> can be shared (such as the same namespace) between multiple elements leading
> to lower memory usage."
>
>
>
>
>
> Comments …………… ?
>
>
>
> ________________________________
>
>
>
> Eran Chinthaka
>
> Lanka Software Foundation
>
>
>
>
>
> > -----Original Message-----
>
> > From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>
> > Sent: Friday, October 22, 2004 6:15 AM
>
> > To: axis-dev@ws.apache.org
>
> > Cc: chintaka@opensource.lk
>
> > Subject: use of immutable value object/interfaces [Re: [Axis2] OM API
>
> > review/changes
>
> >
>
> > Sanjiva Weerawarana wrote:
>
> >
>
> > >"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
> > >
>
> > >
>
> > >>i agree that API should be easy to use but we need to strive for a
>
> > >>balance and be careful to have necessary methods to make API easy to
>
> > >>use (but not too many) and to allow use of immutable objects that can
>
> > >>be shared (such as the same namespace) between multiple elements leading
>
> > >>to lower memory usage.
>
> > >>
>
> > >>
>
> > >
>
> > >I'm confused .. we obviously need to create the OM too. Are we
>
> > >talking about disallowing one to *modify* an already created tree
>
> > >instead of about having methods to create a new OM?
>
> > >
>
> > >
>
> > no that is nto what i meant.
>
> >
>
> > i though about case of tree (OMElement) that is container of objects
>
> > where some of those objects are immutable (like namespaces or attributes).
>
> > so if you need to change element namespace or attribute just create new
>
> > one and replace element namespace or attribute.
>
> >
>
> > exactly the same reasoning goes for immutability of String (including
>
> > multi-thread safety for sharing, caching, low memory usage etc.) and for
>
> > more detailed rationale for immutable "value" object please read (better
>
> > explained that i can):
>
> > http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>
> >
>
> > >If so I'm ok with having the OM be immutable at least initially.
>
> > >
>
> > >
>
> > i was not proposing anyting that radical - i think OMElement should be
>
> > mutable only OMNamespace, OMAttribute should be immutable (and maybe
>
> > OMComment).
>
> >
>
> > >That should give us maximum performance and if you really want
>
> > >to modify the OM then you have to re-generate it. That may bite
>
> > >us badly when dealing with encrypted headers but we can delay
>
> > >that a bit I think. (Decryption will be so slow that creating
>
> > >a new OM will not be a problem :)) However, we should be able
>
> > >to re-parent OM nodes I think.
>
> > >
>
> > >
>
> > that would be interesting: to have read-only API, copy-on-write API and
>
> > full read-write API subsets that are selectable as required by and
>
> > described in metadata of handlers ...
>
> >
>
> > thanks,
>
> >
>
> > alek
>
> >
>
> > --
>
> > The best way to predict the future is to invent it - Alan Kay
>
> >
>
>
--
Ajith Ranabahu
RE: use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Posted by Eran Chinthaka <ch...@opensource.lk>.
Alek's idea of making OMElement mutable and others immutable seems
interesting.
Shall we talk about this in use cases perpectives ???
What are the things we do for the soap message within the engine ??
1. need to access the headers. What we basically do here is that mostly
read the contents of the headers. And sometime may remove and add new
headers. Plus we may modify Element, Texts, Attributes. But I think we
rarely do modifications to comments or namespaces. In this regard, making
OMElement mutable make sense, but I would say that Attributes are highly
subjected to modifications. So making OMAttributes also mutable seems good.
But I agree in making rest of the things immutable.
2. If u think about the body, in current situations this will be accessed
only by either Security handlers or by the provider. (If this is not
correct, I like to see a *use case*, where someone need to access the body).
Provider of course, it needs to just read the contents of the body. SO there
are no modifications to the body.
As Sanjiva said, we can forget the performance discussion about the
supporting of security.
So in conclusion, I think following seems to be ok, for the time being.
OMElement, OMAttribute - mutable
OMNamespace, OMText (or String) - immutable.
Plus I also agree with the idea of "to allow use of immutable objects that
can be shared (such as the same namespace) between multiple elements leading
to lower memory usage."
Comments ..... ?
________________________________
Eran Chinthaka
Lanka Software Foundation
> -----Original Message-----
> From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> Sent: Friday, October 22, 2004 6:15 AM
> To: axis-dev@ws.apache.org
> Cc: chintaka@opensource.lk
> Subject: use of immutable value object/interfaces [Re: [Axis2] OM API
> review/changes
>
> Sanjiva Weerawarana wrote:
>
> >"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> >
> >
> >>i agree that API should be easy to use but we need to strive for a
> >>balance and be careful to have necessary methods to make API easy to
> >>use (but not too many) and to allow use of immutable objects that can
> >>be shared (such as the same namespace) between multiple elements leading
> >>to lower memory usage.
> >>
> >>
> >
> >I'm confused .. we obviously need to create the OM too. Are we
> >talking about disallowing one to *modify* an already created tree
> >instead of about having methods to create a new OM?
> >
> >
> no that is nto what i meant.
>
> i though about case of tree (OMElement) that is container of objects
> where some of those objects are immutable (like namespaces or attributes).
> so if you need to change element namespace or attribute just create new
> one and replace element namespace or attribute.
>
> exactly the same reasoning goes for immutability of String (including
> multi-thread safety for sharing, caching, low memory usage etc.) and for
> more detailed rationale for immutable "value" object please read (better
> explained that i can):
> http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>
> >If so I'm ok with having the OM be immutable at least initially.
> >
> >
> i was not proposing anyting that radical - i think OMElement should be
> mutable only OMNamespace, OMAttribute should be immutable (and maybe
> OMComment).
>
> >That should give us maximum performance and if you really want
> >to modify the OM then you have to re-generate it. That may bite
> >us badly when dealing with encrypted headers but we can delay
> >that a bit I think. (Decryption will be so slow that creating
> >a new OM will not be a problem :)) However, we should be able
> >to re-parent OM nodes I think.
> >
> >
> that would be interesting: to have read-only API, copy-on-write API and
> full read-write API subsets that are selectable as required by and
> described in metadata of handlers ...
>
> thanks,
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>>i agree that API should be easy to use but we need to strive for a
>>balance and be careful to have necessary methods to make API easy to
>>use (but not too many) and to allow use of immutable objects that can
>>be shared (such as the same namespace) between multiple elements leading
>>to lower memory usage.
>>
>>
>
>I'm confused .. we obviously need to create the OM too. Are we
>talking about disallowing one to *modify* an already created tree
>instead of about having methods to create a new OM?
>
>
no that is nto what i meant.
i though about case of tree (OMElement) that is container of objects
where some of those objects are immutable (like namespaces or attributes).
so if you need to change element namespace or attribute just create new
one and replace element namespace or attribute.
exactly the same reasoning goes for immutability of String (including
multi-thread safety for sharing, caching, low memory usage etc.) and for
more detailed rationale for immutable "value" object please read (better
explained that i can):
http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>If so I'm ok with having the OM be immutable at least initially.
>
>
i was not proposing anyting that radical - i think OMElement should be
mutable only OMNamespace, OMAttribute should be immutable (and maybe
OMComment).
>That should give us maximum performance and if you really want
>to modify the OM then you have to re-generate it. That may bite
>us badly when dealing with encrypted headers but we can delay
>that a bit I think. (Decryption will be so slow that creating
>a new OM will not be a problem :)) However, we should be able
>to re-parent OM nodes I think.
>
>
that would be interesting: to have read-only API, copy-on-write API and
full read-write API subsets that are selectable as required by and
described in metadata of handlers ...
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] OM API review/changes
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> i agree that API should be easy to use but we need to strive for a
> balance and be careful to have necessary methods to make API easy to
> use (but not too many) and to allow use of immutable objects that can
> be shared (such as the same namespace) between multiple elements leading
> to lower memory usage.
I'm confused .. we obviously need to create the OM too. Are we
talking about disallowing one to *modify* an already created tree
instead of about having methods to create a new OM?
If so I'm ok with having the OM be immutable at least initially.
That should give us maximum performance and if you really want
to modify the OM then you have to re-generate it. That may bite
us badly when dealing with encrypted headers but we can delay
that a bit I think. (Decryption will be so slow that creating
a new OM will not be a problem :)) However, we should be able
to re-parent OM nodes I think.
Sanjiva.
Re: [Axis2] OM API review/changes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Ajith Ranabahu wrote:
>Hi all,
>I have a small suggestion to make about our OM API. This suggestion is
>based on my experience in writing the OM table implementation.
>Our OM interfaces do not have any setter methods! I find this rather
>annoying since what I do in the table model is to get an empty object
>and fill it with the data from the table (when asked).I can manage the
>filling of values with the current implementation however when the
>objects need to be created and added then there is a problem. With the
>current implementation if I am to implement it then object creation
>will be really cumbersome (Since there are no setter methods the
>changing of attributes will be a difficult workaround) . What I prefer
>is a jdom like thing where you can easily make an object and plug it
>in (Jdom objects have setters as well and that makes it much easier to
>handle programatically)
>My suggestion is to make the OM objects more "bean like" by including
>the necessary setter methods. We may not need the standard bean
>behavior inside though. But our interfaces are more "bean like"
>allowing them to be created and filled with values much more easily.
>
>
>Any thoughts?
>
>
i agree that API should be easy to use but we need to strive for a
balance and be careful to have necessary methods to make API easy to
use (but not too many) and to allow use of immutable objects that can
be shared (such as the same namespace) between multiple elements leading
to lower memory usage.
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] OM API review/changes
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi all,
I have a small suggestion to make about our OM API. This suggestion is
based on my experience in writing the OM table implementation.
Our OM interfaces do not have any setter methods! I find this rather
annoying since what I do in the table model is to get an empty object
and fill it with the data from the table (when asked).I can manage the
filling of values with the current implementation however when the
objects need to be created and added then there is a problem. With the
current implementation if I am to implement it then object creation
will be really cumbersome (Since there are no setter methods the
changing of attributes will be a difficult workaround) . What I prefer
is a jdom like thing where you can easily make an object and plug it
in (Jdom objects have setters as well and that makes it much easier to
handle programatically)
My suggestion is to make the OM objects more "bean like" by including
the necessary setter methods. We may not need the standard bean
behavior inside though. But our interfaces are more "bean like"
allowing them to be created and filled with values much more easily.
Any thoughts?
Ajith
On Wed, 20 Oct 2004 17:03:24 +0600, Eran Chinthaka
<ch...@opensource.lk> wrote:
>
>
>
> I have a small question about Alek's proposed API. I think we decided in the
> Axis Summit to make OM jdk 1.4.2 compatible. But I saw Alek introduced some
> stuff to be compatible with JDK 1.5.
>
> Shall we decide on a JDK version ???
>
>
>
> Plus I add a comment below also J
>
>
>
> Thoughts ???
>
>
>
> Eran Chinthaka
>
>
>
>
>
> >
>
> > hi,
>
> >
>
> > it seems that we are converging on OM API so i did review of current OM
>
> > API and committed to SVN an
>
> > updated version.
>
> >
>
> > as i reviewed existing OM APIs and worked on modifications i concentrated
>
> > on making API more
>
> > lightweight. in particular to allow String to be direct child of OMElement
>
> > and to have as many as
>
> > possible immutable objects in API (such as attributes, namespaces, ...)
>
> >
>
> > the biggest difference is that i removed OMNode as there is no one
>
> > superclass for all XML Information
>
> > Items and this allows to store String *directly* as child of OMElement.
>
> >
>
> > when DOM API wrapper is done over OM API it will have to use Node super
>
> > interface but i wanted to defer
>
> > it to situations only when DOM API is requested by some handler. so there
>
> > may be still some changes
>
> > depending on how much of DOM API we implement ...
>
> >
>
> > the issue that is not clear to me is how OM API can be used to access
>
> > event stream for SOAP:Body
>
> > content (and avoid building OM elements for its content) - how
>
> > isComplete() method should be used in
>
> > this context?
>
> >
>
> [Eran Chinthaka] We are working on a pull API to be plugged in to this OM
> API. And if one has gone and looked at our codes in the SVN, we have used a
> flag (called cache) in the stream wrapper class. If we on this flag (set
> cache on) the wrapper will generate pull events whilst building the OM Model
> in the memory. If we set the flag off (set cache off), only the pull events
> will be generated.
>
> We will put that API also soon.
>
> > for more details see:
>
> > https://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/a
>
> > lek/axiom/
>
> > https://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/a
>
> > lek/axiom/infoset_api/org/apache/axis/om/
>
> > and
>
> > http://wiki.apache.org/ws/FrontPage/Architecture/OM
>
> >
>
> > thanks,
>
> >
>
> > alek
>
> >
>
> > --
>
> > The best way to predict the future is to invent it - Alan Kay
>
> >
>
>
--
Ajith Ranabahu
RE: [Axis2] OM API review/changes
Posted by Eran Chinthaka <ch...@opensource.lk>.
I have a small question about Alek's proposed API. I think we decided in the
Axis Summit to make OM jdk 1.4.2 compatible. But I saw Alek introduced some
stuff to be compatible with JDK 1.5.
Shall we decide on a JDK version ???
Plus I add a comment below also :-)
Thoughts ???
Eran Chinthaka
>
> hi,
>
> it seems that we are converging on OM API so i did review of current OM
> API and committed to SVN an
> updated version.
>
> as i reviewed existing OM APIs and worked on modifications i concentrated
> on making API more
> lightweight. in particular to allow String to be direct child of OMElement
> and to have as many as
> possible immutable objects in API (such as attributes, namespaces, ...)
>
> the biggest difference is that i removed OMNode as there is no one
> superclass for all XML Information
> Items and this allows to store String *directly* as child of OMElement.
>
> when DOM API wrapper is done over OM API it will have to use Node super
> interface but i wanted to defer
> it to situations only when DOM API is requested by some handler. so there
> may be still some changes
> depending on how much of DOM API we implement ...
>
> the issue that is not clear to me is how OM API can be used to access
> event stream for SOAP:Body
> content (and avoid building OM elements for its content) - how
> isComplete() method should be used in
> this context?
>
[Eran Chinthaka] We are working on a pull API to be plugged in to this OM
API. And if one has gone and looked at our codes in the SVN, we have used a
flag (called cache) in the stream wrapper class. If we on this flag (set
cache on) the wrapper will generate pull events whilst building the OM Model
in the memory. If we set the flag off (set cache off), only the pull events
will be generated.
We will put that API also soon.
> for more details see:
> https://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/a
> lek/axiom/
> https://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/a
> lek/axiom/infoset_api/org/apache/axis/om/
> and
> http://wiki.apache.org/ws/FrontPage/Architecture/OM
>
> thanks,
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>