SAXException deserializing unknown element - bug or feature?

["Philoon, Jay" <Ja...@fmr.com>]

	Web services purport to offer "loose coupling" between producers and
consumers. However, this term is currently not defined - at least in terms
of what is expected of an implementation. One must therefore go to the
philosophy of Internet protocols in general, in which tolerance and
resilience are considered desirable objectives. For instance, an HTTP
request can have many header fields. There is no requirement that a receiver
understand all of the fields; the receiver looks for what it needs and
ignores the rest. The same philosophy should extend to Web services. 
	
	Unfortunately, Apache Axis 1.1 creates brittle bindings to XML
schemas.  The receipt of any new element by an Axis consumer implementation
causes it to stop parsing, throwing a SAXException instead.  Loose coupling
- not! (Interestingly, .Net consumers have no trouble ignoring additional
elements.) 
	
	In our case, there were two options for fixing the Apache Axis
consumer. The first was to regenerate and to retest the client each time the
producer changed, even for trivial, backwardly-compatible changes. This was
deemed undesirable. The second option was to make the code more resilient.
This was accomplished by going into the Apache Axis 1.1 code and modifying
it to skip unknown elements. This in fact turned out to be very easy. The
change was this, in
org.apache.axis.encoding.ser.BeanDeserializer.onStartChild: 
	
	if (propDesc == null) { 
		// No such field 
		return null; // JTP 
		/* 
		throw new SAXException( 
		Messages.getMessage("badElem00", javaType.getName(),
localName)); 
		*/ 
	} 
	
The return of a null at this point is equivalent to a nil XML element being
encountered.
	I would be interested in knowing if there is some way of telling
Axis to be strict or lax in its checking.  Or is this SAXException always a
desirable feature that should not be subverted?

Jay Philoon