axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@opensource.lk>
Subject Re: [Axis2] OM API
Date Tue, 07 Dec 2004 10:03:42 GMT
Looks good, but I think getRootElement should become getDocumentElement. 
There's nothing called a "root element" .. there's a root node and a
document element in an XML document. 

(I was on the XSLT working group with James Clark. James is one of the
sharpest people I've ever met and never tolerated imprecise use of
words .. so you can blame him for my being a pain about words now ;-).)

Sanjiva.
  ----- Original Message ----- 
  From: Eran Chinthaka 
  To: axis-dev@ws.apache.org 
  Sent: Tuesday, December 07, 2004 3:18 PM
  Subject: RE: [Axis2] OM API


  OK, now this is implemented. Srinath, so no worries and now OM is "usable" for u J J

   

  One can use the OMXMLBuilderFactory to create the builders mentioned in the figure.

   

  Usage is shown in the StAXOMBuilderTest class. 

   

  One thing I had modify was that, earlier OMXMLParserWrapper had the method getOMEnvelope.
Now its refactored as

  public OMElement getRootElement()

   

  If someone is using getRootElement method of StAXSOAPModelBuilder then he has to cast the
returned OMElement to a SOAPEnvelope.

   

  Comments .. ??

   

  Eran Chinthaka

   

   

  Oh yes. OM is getting ready for that too. :)

   

  I'm making some changes to the Builders, so that one builder can create the SOAP specific
model and the other can create only the OM model.

   

  For example;

       
        



  The StAXOMBuilder will generate a Structure, starting from OMDocument. This can be built
from *any* XML.

  The StAXSOAPModelBuilder (name is bit weird, I hate putting names L, suggestions ??) will
generate a structure, starting from SOAPEnvelope. This can be built only from a SOAP message.

   

  The same thing can be done for XPPBuilder as well.

   

  But one need not bother about creating this, as all the things will be provided via factories.

   

  Thoughts ??

   

  Eran Chinthaka

   

   

  >>+1 :) let me add a new requirements .. when the user uses the OM one

  >>of the common use case is to get a random XML segment .. create a OM

  >>Elelemt out of it and add it to the current OM. Can we address this?

  >> 

  >>I think we aim for XML in XML out and belive this is utility that make

  >>the OM more usable!

  >>Thanks

  >>Srinath

  >> 

  >> 

  >>On Mon, 06 Dec 2004 12:26:20 -0500, Aleksander Slominski

  >><aslom@cs.indiana.edu> wrote:

  >>> +1 that is the picture i hand in my mind too and i think o.a.axiom and

  >>> o.a.axis2.om  to add axis2 context to axiom and o.a.axis2.soap for soap

  >>> should be easy to understand an to reuse (modularity!)

  >>> 

  >>> thanks,

  >>> 

  >>> alek

  >>> 

  >>> 

  >>> 

  >>> Eran Chinthaka wrote:

  >>> 

  >>> >

  >>> >

  >>> > Hi,

  >>> >

  >>> >

  >>> >

  >>> > I re-factored the names of the classes to SOAP specific ones in the

  >>> > prototype2 area.

  >>> >

  >>> >

  >>> >

  >>> > OMEnvelope à SOAPEnvelope

  >>> >

  >>> > OMHeader à SOAPHeader

  >>> >

  >>> > OMBody à SOAPBody

  >>> >

  >>> > OMHeaderBlock à SOAPHeaderBlock

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> > We would like to propose following architecture for OM.

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> > OM in the base, has full infoset support. The intention of this is

  >>> > that, even though SOAP do not require full infoset support, one might

  >>> > send a complete XML doc as an attachment. If we can help the

  >>> > application to access using OM, that would be nice. I think this is

  >>> > what Alek, has once expressed.

  >>> >

  >>> >

  >>> >

  >>> > And we can improve OM, so that it will be a better xml model, on its

  >>> > own. So how about moving it to a package like org.apache.axiom and not

  >>> > org.apache.*axis*.om

  >>> >

  >>> > But for M1 now, we don't need to support full infoset, we just put

  >>> > whatever absolutely required for now in to OM. That means, PI Support,

  >>> > DTD Support will come later.

  >>> >

  >>> >

  >>> >

  >>> > And on top of that we have a SOAP specific API. Like SOAPEnvelope,

  >>> > SOAPHeader, etc., These will be extensions of OMElement, but will

  >>> > provide more convenience to the user.

  >>> >

  >>> >

  >>> >

  >>> > Comments and thoughts ..... ?? J

  >>> >

  >>> >

  >>> >

  >>> >

  >>> >

  >>> > ----------------------------------------------------------------------

  >>--

  >>> >

  >>> > *Eran Chinthaka*

  >>> >

  >>> > *Lanka Software Foundation*

  >>> >

  >>> >

  >>> >

  >>> 

  >>> --

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

  >>> 

  >>> 

   

Mime
View raw message