The problem is that strict versioning and loose coupling do not really
match.
I think it is a good idea to give up some strictness to achieve a looser
coupling in services. Btw. by using xsd:any you would do almost the same
just with a lot more effort. For service stacks that require validation
you can still produce a wsdl with xsd:any if it is really necessary.
I just looked up the principle I mentioned:
http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law
This principle is well respected in engineering. Examples mentioned are
E-Mail and digital circuits. I think also the TCP/IP implementations
follow it.
I tested this in practice and had good experiences with it. The fear of
something breaking in production is not real. Before you put a new
client in production you will test it with the old provider in a test
network. If it breaks you will know before production.
Christian
Am 26.08.2011 08:04, schrieb Dennis Sosnoski:
Hi Christian,
It's true that JAXB ignores schemas by default, just matching elements
by name and ignoring any extra (or missing) ones. But if you start
developing web services on this basis you're setting yourself up for
problems. You may test code using your sloppy JAXB code and think that
everything is fine, then deploy into production and find that everything
breaks when working with software that actually pays attention to the
schema.
The principle of being strict in what you send, open in what you expect,
is what led to the browser wars on the web. Each browser implemented its
own way of handling things which weren't correct, so web sites might
look good with one browser but not with another. We'd all have been much
better off if the browser builders had all agreed to just reject
anything which was not correct. XML is rigidly structured and
unforgiving of deviations in order to avoid this type of problem.
- Dennis
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
