> Yes I am truly with option 1. > When looking back at the things I feel the same as Dasarath. We could > have left out certain changes all together. Currently I feel the > architecture is corrupted to a certain extent. If someone goes through > the class hierarchies there will be certain places where its not > streamlined. > I feel what we did with implementing SOAP classes was not suitable.( > Not saying it is wrong. A SOAP object hierarchy is a must!. But the > way we have implemented the SOAP classes is "too tight" with OM). We > should have thought of a looser implementation. Builder checks for > SOAP compliancy and everything else that matters should have been > more "stream lined". > Since we have a lot of work ahead that depends on OM I am ok with any > effort to refactor and correct anything with OM right now. +1, You know I too happy to make the OM and SOAP classes seperate. My view is OM should represents XML (bit relaxed XML without PI's ect) and build a layer on the OM for SOAPEnvelope ect .. that do the validation ect.
But if OM accepts the responisbility of creating the SOAPEnvelope..ect then it is the reposnibility of OM to validate the SOAPEnvelope..ect. I belive we discussed and agree on this earlier Thanks Srinath > On Mon, 21 Mar 2005 02:38:58 -0800 (PST), Dasarath Weeratunge > <[EMAIL PROTECTED]> wrote: > > If you are in doubt about how much recent > > architectural changes may have affected (or killed) OM > > performance please look at the following test results: > > > > https://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/dasarath/om/$1/ > > > > --Dasarath > > > > --- Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > This will some relate to the thread "Doubt on Detail > > > Element in SOAPFault". > > > > > > AXIOM was not meant to check the compliance with > > > SOAP spec or anything else. > > > It will just hold the infoset. The reason behind me > > > putting a SAAJ like api > > > on top of OM was to provide developer convenience. > > > For example, rather than > > > saying element.getFirstElement(), developers love to > > > use > > > envelope.getHeader(). So, that was the intention of > > > providing that sort of > > > SOAP jargon in to Axiom. This was our initial idea. > > > > > > But later, some have put some checks in to the AXIOM > > > SOAP api. And the > > > earlier thread also was asking about this > > > validation. > > > > > > So I have a small question on this. What should we > > > have in AXIOM ?? > > > > > > 1. Shall we "KISS" Axiom, and let it be just a info > > > set holder. > > > - If this is the case, this will not affect the > > > performance, due to > > > validation and stuff. And if we make it like this > > > how we gonna provide > > > validation or do we need to provide validation. Can > > > we leave this up to the > > > user ? > > > 2. Shall we make AXIOM SOAP stuff do validation on > > > SOAP 1.1 spec as well. > > > - This will definitely affect the performance. > > > > > > > > > IMHO, I prefer option 1, which is basically my > > > initial idea as well. > > > > > > What do you all think about this ? > > > > > > > > > Thanks, > > > Eran Chinthaka > > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > -- > Ajith Ranabahu >
