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.