using xsd:any for extensible schema

Question

Until now, I've been handling extensions by defining a placeholder element that has "name" and "value" attributes as shown in the below example

<root>
   <typed-content>
      ...
   </typed-content>
   <extension name="var1" value="val1"/>
   <extension name="var2" value="val2"/>
....
</root>

I am now planning to switch to using xsd:any. I'd appreciate if you can help me choose th best approach

1. What is the value add of xsd:any over my previous approach if I specify processContents="strict"
2. Can a EAI/ESB tool/library execute XPATH expressions against the arbitrary elements I return
3. I see various binding tools treating this separately while generating the binding code. Is this this the same case if I include a namespace="http://mynamespace" and provide the schema for the "http://mynamespace" during code gen time?
4. Is this WS-I compliant?
5. Are there any gotchas that I am missing?

Thank you

Answer 1

1. Using <xsd:any processContents="strict"> gives people the ability to add extensions to their XML instance documents without changing the original schema. This is the critical benefit it gives you.
2. Yes. tools than manipulate the instances don't care what the schema looks like, it's the instance documents they look at. To them, it doesn't really matter if you use <xsd:any> or not.
3. Binding tools generally don't handle <xsd:any> very elegantly. This is understandable, since they have no information about what it could contain, so they'll usually give you an untyped placeholder. It's up the the application code to handle that at runtime. JAXB is particular (the RI, at least) makes a bit of a fist of it, but it's workable.
4. Yes. It's perfectly good XML Schema practice, and all valid XML Schema are supported by WS-I
5. <xsd:any> makes life a bit harder on the programmer, due to the untyped nature of the bindings, but if you need to support arbitrary extension points, this is the way to do it. However, if your extensions are well-defined, and do not change, then it may not be worth the irritation factor.

Answer 2

Regarding point 3

Binding tools generally don't handle very elegantly. This is understandable, since they have no information about what it could contain, so they'll usually give you an untyped placeholder. It's up the the application code to handle that at runtime. JAXB is particular (the RI, at least) makes a bit of a fist of it, but it's workable.

This corresponds to the @XmlAnyElement annotation in JAXB. The behaviour is as follows:

@XmlAnyElement - Keep All as DOM Nodes

If you annotate a property with this annotation the corresponding portion of the XML document will be kept as DOM nodes.

@XMLAnyElement(lax=true) - Convert Known Elements to Domain Objects

By setting lax=true, if JAXB has a root type corresponding to that QName then it will convert that chunk to a domain object.

• http://bdoughan.blogspot.com/2010/08/using-xmlanyelement-to-build-generic.html