WS-I Submission W3C XML Schema User Experiences Workshop June 2005 Redwood Shores, CA, USA Erik Johnson, Epicor Software

Outline WS-I Schema Working Group Efforts Experience Report  Schema Producers / Authoring  Toolkits  Testing Resources

WS-I Organization An open industry effort chartered to promote Web Services interoperability across platforms, applications and programming languages. A standards integrator to help Web services advance in a structured, coherent manner Approximately 130 member organizations  70% vendors, 30% end-user organizations  Strong non-U.S. membership, including very influential Japan SIG

WS-I Schema Work Plan WG Work began in November 2004 Discussions were high-level and constrained to using W3C XML Schema in web services  Interoperability issues with the W3C XML Schema specification itself were not the problem Messages on the wire can be determined to conform to service descriptions  Unsure that a “profile” (subset) is feasible Risks of “unraveling” the specification by disallowing features How else to describe an Infoset in a platform-independent way?

Schema Producers / Authoring Extensibility & composition mechanisms  Implementers need to create derivative schemas and compose schemas into WS descriptions  Extensibility points are awkward to describe UPA is not known or correctly understood and some tools intentionally ignore the rule Modularity practices are not well-understood  Some users attempt to abstract data from behavior in WSDL  Namespace-based mechanisms are not agreed-to  Need an element co-occurrence construct in message definitions  Most attempts to create any modularity constructs are not likely to be recognized by human or machine consumers

Toolkit Support Inferring XML Schema documents to/from language types is difficult  Special attribution or other extensions are used to help in serialization  Some developers don’t want to serialize objects – others do  Some want RPC semantics – others don’t Few implementers use XML Schema validation  Some validation aspects get handled by combinations of type serializers, SOAP processors, and hand-rolled code

Toolkit Support (2) Many schema authors prefer designing schemas independent of any specific platform or toolkit  Avoids bias  Some want to leverage unique capabilities of XML in representing data This puts more pressure on “downstream” platforms and toolkits  Broadens the set of XML Schema features and constructs generally used  Modularity or other abstraction mechanisms – well thought-out or not – complicate the resulting schemas further

Toolkit Support Conclusions Interoperability issues seem to be “witnessed” more at design-time  Ungraceful fallbacks when unsupported XML Schema constructs are encountered are a problem  Little agreement what “supported” might mean What to do?  Some feel that the WS-I should profile XML Schema and define a subset to make language mapping and programmability easier.  Others feel that the XML Schema Specification itself is not the issue and that toolkits simply need to improve What is the fear?  Web Service standards will split into camps of de-facto profiles  Interoperability will suffer

Testing Resources Users want a way to test platforms and toolkits against XML schemas actually encountered  Schema examples need to culled from real-world providers rather than some academic sample  Tests might include running endpoints Different users have different expectations and requirements Ability to test locally if desired is ideal  “In the privacy of your own home”  Independent of individual (and possibly dated) toolkit claims

Conclusions Little support for creating an XML Schema profile Composition, versioning, and modularity are pain points for schema authors Toolkit support for some schema constructs is problematic  But no agreement about the best course of action An improved set of test resources based on schemas in the wild would be appreciated  With an ability to run them locally

WS-I Submission Thanks