Dennis Sosnoski wrote:
doc/lit means you don't need to care about 1 or 3 - you specify the XML format and let the clients worry about how they want to handle it. 2 is a separate issue...
Really? I can see how it would be liberating to think this way but I can break away from wanting nice clean language binding (Java, C#, C++) for my doc/lit services.
ASP.NET's ASMX seems to have done and it for many but not all cases. Perhaps this is just too elusive to hope for and thunking to XML is the way forward? The Various XML programming APIs have improved since DOM/SAX with pull parsers, JDOM and what have you so maybe folks wont feel the need to bind XML types to Java types... Are we there yet?
my personal opinion is that XML API should allow you to represent XML message that contains both XML infoset and Java native types (generated by XmlBeans, Castor, JAXB, whatnot) and let runtime figure out how to materialize XML 1.0 serialization when the message goes on the wire. here is example of what i think about:
XmlElement xmlFragment = ...' //represents XML such as <hello/>
XmlElement message = ...;
message.addElement("foo").addElement(xmlFragment); //add XML
message.addElement("bar").addChild("text"); // add String
message.addElement("bar").addChild(new XmlString("another xsd:string")); message.addElement("baz").addChild(new Integer(7)));
and when you serialize message you should get
<message><foo><test/></foo><bar>text</bar><bar>another xsd:string</bar><baz>7</baz></message>
ready to be wrapped into SOAP:Body (or not) and send wherever you want.
that is at least what i think.
alek
-- The best way to predict the future is to invent it - Alan Kay
