Thanks Dennis. We thought about providing a xs:any element for extensibility. However, this poses a few other problems as you mentioned below. I wonder whether it's possible to do xs:any with maxOccurs="unbounded" as a way of providing multiple arbirerary elements without violating XML schema.
*<quote>* *"So there's no easy way to get the kind of flexibility you want whilestaying compatible with XML schema. JAXB will give you the client-sideflexibility, but it does this by basically ignoring the schema and onlyprocessing the elements it understands. Clients using tools which takethe schema more seriously will fail with your added data."* *</quote>* Very true. This is why we started investigating whether all mainstream stacks have an option to do lax versioning. Cheers, -Buddhike On Wed, Mar 2, 2011 at 10:20 AM, Dennis Sosnoski <d...@sosnoski.com> wrote: > Hi Buddhike, > > As I mentioned in my reply to a separate email on a similar issue, it's > possible to design your schemas with extension points for adding more data > in the future by using the xs:any element. The big limitation is that if you > want to use the same namespace for your extension elements, the xs:any must > be the last item in an xs:sequence and must follow a required element (this > is a somewhat stupid limitation of XML schema). That's not so bad if you're > only adding a few extensions, but it causes problems when you want to > provide an updated schema that includes the extension elements. > > One way around this limitation is to use a new namespace for each set of > added elements, but this leads to namespace proliferation and a lot of > confusion. Another is to use an optional wrapper element around the added > content, but that also leads to ugliness since a new wrapper element would > be required for each set of extensions. > > So there's no easy way to get the kind of flexibility you want while > staying compatible with XML schema. JAXB will give you the client-side > flexibility, but it does this by basically ignoring the schema and only > processing the elements it understands. Clients using tools which take the > schema more seriously will fail with your added data. > > - Dennis > > > > On 03/02/2011 12:09 PM, Buddhike de Silva wrote: > > Thanks Josef. I like your idea. But this would be a little complicated in > terms of what we are trying to achieve. To put more context around... We are > building a public Web Service. And we want to be interoperable with main > stream Java stacks. When it comes to releasing the next version of the > product, we want to ensure that our clients don't break regardless of the > stack they are using. We also want to ensure we have the fastest upgrade > path for certain things we consider as non breaking changes. > > One of them is adding a new optional member to type. We could consider that > as a breaking change and version our endpoints accordingly but given the > number of small changes we could anticipate, we'd rather avoid going down > that path. However, we could only do that, if our clients using Java had > the option to do lax visioning :-). > > We could use the dictionary based solution you mentioned. However, this > would hide the strongly typed/hierarchical view of our data from our clients > using the subsequent versions. > > Cheers, > > -Buddhike > > On Tue, Mar 1, 2011 at 6:21 PM, Stadelmann Josef < > josef.stadelm...@axa-winterthur.ch> wrote: > >> Hi Buddhike >> >> >> >> Denis é all is right, breaking the contract is bad. But you can also think >> about how a collection would be serialized, given a collection of strings >> can be seen as a type. While this collection is i.e. a collection of >> elements and each element has name value pairs of type string. If you can >> serialize and de-serialize a collection then you can add as many elements as >> you like. This is our approach to exchange unforeseen amounts of screen data >> from transaction masks with our server up to the database tables. The axis2 >> client is very well in receiving and responding with AXIOM OMElement. And an >> OMElement can consist any series of nodes parent with child's and child's >> with siblings. >> >> >> >> The axis2 examples shows a service, guess one of the echo examples, how an >> OMElement is exchanged from an axis2 client with the axis2 server. >> >> Now it is up to you to add more nodes to this OMElement and send it to the >> server, and receive one from the server. If that works record what is >> exchanged an make the same between a WCF Client and a WCF Server. Then take >> a look at the difference using a SOAP Monitor or a TCPMONITOR. >> >> >> >> It’s a hard way but it works. >> >> >> >> Cheers >> >> >> >> *Von:* Buddhike de Silva [mailto:buddhike.desi...@geeksdiary.com] >> *Gesendet:* Dienstag, 1. März 2011 08:33 >> *An:* Dennis Sosnoski >> *Cc:* java-user@axis.apache.org >> *Betreff:* Re: Axis Serialization Behavior >> >> >> >> Thanks a lot Dennis. >> >> Cheers, >> >> -Buddhike >> >> On Tue, Mar 1, 2011 at 5:30 PM, Dennis Sosnoski <d...@sosnoski.com> wrote: >> >> Ah, I hadn't realized you were using Axis(1). With Axis2 you can select >> the data binding using a parameter to Wsdl2Java. You should be able to see >> examples included in the Axis2 download, or you can try my code from this >> article: http://www.ibm.com/developerworks/java/library/j-jws8.html I >> haven't tried the code from the article with the latest Axis2 releases, but >> hopefully it'll still work correctly. >> >> - Dennis >> >> >> >> >> On 03/01/2011 07:58 PM, Buddhike de Silva wrote: >> >> Thanks Dennis. Do you know of a link with some sample code on how to do >> this? Sorry, I'm not really familier with Axis2. Thanks again. >> >> Cheers, >> >> -Buddhike >> >> On Tue, Mar 1, 2011 at 4:46 PM, Dennis Sosnoski <d...@sosnoski.com> wrote: >> >> Hi Buddhike, >> >> The handling of unexpected XML elements is determined by the data binding >> technique used. JAXB is the sloppiest data binding supported by Axis2 (on a >> par with WCF), and if you change to that you should be ok. >> >> - Dennis >> >> Dennis M. Sosnoski >> Java SOA and Web Services Consulting<http://www.sosnoski.com/consult.html> >> Axis2/CXF/Metro SOA and Web Services >> Training<http://www.sosnoski.com/training.html> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html> >> >> >> On 02/28/2011 10:17 PM, Buddhike de Silva wrote: >> >> Anyone? (please... :-)) >> >> On Sun, Feb 27, 2011 at 4:28 PM, Buddhike de Silva < >> buddhike.desi...@geeksdiary.com> wrote: >> >> Hi All, >> >> We are doing some interop tests between Axis and WCF. In our WCF service >> we have a type like this. >> >> [DataContract] >> >> public class CompositeType >> >> { >> >> [DataMemeber] >> >> public bool BoolValue {get; set;} >> >> } >> >> That results in a schema similar to the following. >> >> <xs:complexType name="CompositeType"> >> <xs:sequence> >> <xs:element name="BoolValue" type="xs:boolean" minOccurs="0"/> >> </xs:sequence> >> </xs:complexType> >> <xs:element name="CompositeType" type="tns:CompositeType" >> nillable="true"/> >> >> >> We can generate Axis code with the WSDL/Schema generated by WCF service >> and communicate with the service. However, if we add another property to >> CompositeType class on the WCF server side, it breaks the Axis client. It >> throws an exception saying it's reading an element that was unexpected. Our >> understanding Axis is capable of lax processing of XML (that is, if it >> encounters anything that's not recognized, serializer simply discards them). >> Could someone pleasae let us know which settings we should use to enable lax >> processing of messages? Many thanks in advance. >> >> Cheers, >> >> -Buddhike >> >> >> >> >> >> >> > >
