Return-Path: Delivered-To: apmail-axis-java-user-archive@www.apache.org Received: (qmail 63565 invoked from network); 2 Mar 2011 07:46:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Mar 2011 07:46:29 -0000 Received: (qmail 55622 invoked by uid 500); 2 Mar 2011 07:46:28 -0000 Delivered-To: apmail-axis-java-user-archive@axis.apache.org Received: (qmail 55207 invoked by uid 500); 2 Mar 2011 07:46:24 -0000 Mailing-List: contact java-user-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@axis.apache.org Delivered-To: mailing list java-user@axis.apache.org Received: (qmail 55199 invoked by uid 99); 2 Mar 2011 07:46:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Mar 2011 07:46:23 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [206.123.75.163] (HELO sosnoski.com) (206.123.75.163) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Mar 2011 07:46:15 +0000 Received: from linux.site (125-239-96-192.jetstream.xtra.co.nz [125.239.96.192]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id p227joUI022814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 02:45:53 -0500 Message-ID: <4D6DF65A.1060901@sosnoski.com> Date: Wed, 02 Mar 2011 20:48:42 +1300 From: Dennis Sosnoski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6 MIME-Version: 1.0 To: Buddhike de Silva CC: java-user@axis.apache.org Subject: Re: Axis Serialization Behavior References: <4D6C9657.2000201@sosnoski.com> <4D6CA0A9.2070102@sosnoski.com> <4D6D8D5C.1070906@sosnoski.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000705070501000703050303" --------------000705070501000703050303 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/02/2011 07:54 PM, Buddhike de Silva wrote: > > 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. > Yes, xs:any with maxOccurs="unbounded" is fine - but the problem is that it only works for one extended schema, unless your extended schema ends with a new required element. So you could go from schema1: to schema2: ... to schema3: ... ... all while maintaining compatibility (providing the new required elements were always present in the server response). But you have to add a new required element with each update. Attributes are a much cleaner solution for working with simple values. > // > > /"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."/ > > // > > Very true. This is why we started investigating whether all mainstream > stacks have an option to do lax versioning. > It's not a good idea to count on users working with stacks which ignore the schema message description. If you take this approach it will work ok with WCF or JAXB developers, but you're likely to run into groups using other tools - and when they point out you're violating your own schema they'll be correct, which might be hard to explain to your management. - Dennis --------------000705070501000703050303 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/02/2011 07:54 PM, Buddhike de Silva wrote:

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.


Yes, xs:any with maxOccurs="unbounded" is fine - but the problem is that it only works for one extended schema, unless your extended schema ends with a new required element. So you could go from schema1:

� <xs:element name='a' type='xs:string'/> <!-- required element -->
� <xs:any maxOccurs='unbounded'/>

to schema2:

� <xs:element name='a' type='xs:string'/> <!-- required element -->
� <xs:element name='b' type='xs:string' minOccurs='0'/>
� ...
� <xs:element name='c' type='xs:string' /> <!-- required element -->
� <xs:any maxOccurs='unbounded'/>

to schema3:

� <xs:element name='a' type='xs:string'/> <!-- required element -->
� <xs:element name='b' type='xs:string' minOccurs='0'/>
� ...
� <xs:element name='c' type='xs:string' /> <!-- required element -->
� <xs:element name='d' type='xs:string' minOccurs='0'/>
� ...
� <xs:element name='e' type='xs:string' /> <!-- required element -->
� <xs:any maxOccurs='unbounded'/>

all while maintaining compatibility (providing the new required elements were always present in the server response). But you have to add a new required element with each update.

Attributes are a much cleaner solution for working with simple values.

<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.


It's not a good idea to count on users working with stacks which ignore the schema message description. If you take this approach it will work ok with WCF or JAXB developers, but you're likely to run into groups using other tools - and when they point out you're violating your own schema they'll be correct, which might be hard to explain to your management.

� - Dennis
--------------000705070501000703050303--