XSD in Web Services Douglas Purdy Distributed Systems Group Microsoft

Web Services Model

Microsoft Web Services Principles Support serializable CLR types –Support v1 -> v2 -> v1 scenarios without loss –Support graph semantics –Support types to author application protocols –Work to ensure usability on the “other side” Support all of XSD –If it is a valid XSD our tools should support it –The binding code may not be strongly-typed “All schemas are supported, some are more supported than others”

Supporting serializable CLR types A “de facto” XSD profile exists for WS –Defined by SoapBuilders –Largely sequence and XSD simple types We added some features to the profile –Completely schema valid & interoperable –Versioning, Graphs, Generics, … Causes issues with the “other side” –Doesn’t support the constructs we use –Doesn’t generate “usable” code when they do

Supporting all of XSD Full XSD  CLR mapping is hard –We tried it and it really wasn’t usable We have great XML programming models –This is a reasonable way to support all of XSD We are investing in even better XML tools –No details here ;-) Currently, we support “fallback generation” –Generate the most “usable” typed model –Generate a backup typed model (old technology) –Generate a Message (model for a SOAP envelope)

Things to Explore UPA, UPA, UPA, UPA xsi:id & xsi:ref must-understand? Domain specific profiles of XSD (WS-I, …)