Hi Dennis On Fri, Aug 26, 2011 at 7:04 AM, Dennis Sosnoski <[email protected]> wrote: > 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.
All browsers will ignore unrecognized HTML tags which is the underlying idea behind the forward compatibility. I think what you are referring to has mostly to do with non-portable scripts being deployed at individual sites, ex, IE and Firefox will probably show the same dynamic content slightly differently... Cheers, Sergey >XML is rigidly structured and > unforgiving of deviations in order to avoid this type of problem. > > - Dennis > > > On 08/26/2011 05:43 PM, Christian Schneider wrote: >> Hi Derek, >> >> I used the xsd:any element for some time. The problem is that it >> create a lot of problems parsing the xml. Additionally it adds an >> unnatural element to the data types that makes your schemas more >> difficult to read. >> >> Then I remembered an early principle of the internet. Be strict in >> what you send, be open in what you expect. So for services this means >> when sending out always make sure you follow the schema of the service >> version >> you implement. When receiving a message try to process it even if it >> is not completely correct. >> So in the end I went with the easiest way to simply not use >> validation. You have to write a set of tests for your services anyway >> as validation can not find a big part of the errors. Without >> validation many of the problems simply go away. >> >> For example if you have a new element in a type and a newer sender >> sends it to an old service provider then cxf will just ignore the >> unknown element on the receiver side. So if the rest of the data still >> forms a usable request in the old schema then he old impl can simply >> process it. So by using this you can make many seemly incompatible >> changes compatible. >> >> Christian >> >> >> >> >> Am 24.08.2011 23:01, schrieb dstainer: >>> I know this topic has been broached in various forms over the years. >>> However, >>> I'd like to compare notes with other folks that have implemented SOAP >>> web >>> service versioning schemes, see if anything has changed from the earlier >>> discussions on the topic. >>> >>> I've read through a number of different resources [1][2][3][4], and I'm >>> curious to hear about other people's experiences with this topic. >>> Specifically, I'm curious about the following: >>> >>> - Code first vs. Contract first and why within the context of versioning >>> - Use of versioned namespaces to separate operations per [1] >>> recommendations >>> - How did you design for forward compatibility i.e. use of >>> <xsd:any>/@XmlAnyElement >>> - How did you design for backwards compatibility i.e. optional elements >>> - Did you use strict/flexible/loose versioning [2] >>> - Any testing of backwards compatibility between minor versions >>> - How did CXF help/hinder your ability to carry out versioning of >>> services >>> >>> In addition, to those questions I'm also curious to hear about more >>> general >>> thoughts on the topic. What worked well and what didn't? Any big >>> gotchas or >>> lifesavers that I should be aware of? >>> >>> Thanks >>> Derek >>> >>> References >>> >>> [1] - >>> http://blogs.iona.com/sos/20070410-WSDL-Versioning-Best-Practise.pdf >>> WSDL Versioning Best Practise >>> [2] - >>> http://www.infoq.com/resource/articles/Web-Service-Contracts/en/resources/ERL_WSContractVersioning_013613517X_20-22.pdf >>> >>> Web Service Contract Design and Versioning for SOA (Chapters 20-22) >>> [3] - http://www.infoq.com/articles/contract-versioning-comp2 Contract >>> Versioning, Compatibility and Composability >>> [4] - http://www.xml.com/lpt/a/1492 Extensibility, XML Vocabularies, >>> and >>> XML Schema >>> >>> -- >>> View this message in context: >>> http://cxf.547215.n5.nabble.com/SOAP-Web-Service-Versioning-tp4731875p4731875.html >>> Sent from the cxf-user mailing list archive at Nabble.com. >>> >> > -- Sergey Beryozkin http://sberyozkin.blogspot.com Talend - http://www.talend.com
