>> But there come the design question. To me SOAP elements are particular >> XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which >> was quite what I have in mind [1]. >> >> I think the main problem (to me) is that XMLElement in Smalltalk has an inst >> var containing all children node. I think this is different in java. The >> consequence is to model SOAPEnvelope (subclass of XMLElement), I can't >> really add a body and header field respectively for the SOAPHeader and >> SOAPBody object. Instead I should put them in the children collection node. >> Is it a good practice ? Do I use a factory to ensure there's at least one >> and only one body and eventually a header ? Any other pattern for such >> situations ? > > hmm.. the existence if separate class for each of xml elements doesn't > automatically means that it can validate a SOAP document that it is > well formed, isn't?
yes sure, but I thought it will help... > > >> Or would you avoid to subclass ? >> >> Secondary question: As I found this java API, I got really tempted to use a >> similar organization. It it authorized ? I couldn't really parse the license >> file :) >> > > As to me, i'd better leave the xml domain as soon as possible by > validating it and then parsing its elements into something, which is > reification of actual SOAP query/response model , without trying to > resemble an xml dom tree. yes I get your point, I'll get something simpler first. Thx > >> Thanks in advance, >> >> Cédrick >> >> [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/ >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >
