Use case for xsd:any restrictions at design time

["Glen Daniels" <gdaniels@sonicsoftware.com>]

As discussed at the F2F, here is a brief use case for why some sort of
design-time metadata which details a refinement of xsd:any might be
useful.

---

I'm using a management tool to do work with a wide variety of back end
services.  Each such service implements a given WSDL interface, and in
amongst a few standard RP properties for the base interface is an
xsd:any which acts as a placeholder for other data types that are
utilized by individual service instances.  The actual field of data
types that might go in there is not infinite - it is managed by a
separate system of some kind.  On the other hand, it wants to remain
flexible in the schema (hence the xsd:any) to account for extensibility.


At design time (example - I'm building a dashboard GUI app for a
particular set of related services), I want to read the WSDL for a
particular instance of the interface, and have some kind of clue as to
what the actual RP schema looks like for that instance.  If there were a
standard place to put this kind of information (which can be thought of
as policy, perhaps), that would be most useful.

Thanks,
--Glen