WS-I Submission

W3C XML Schema User Experiences Workshop

21-22 June 2005Redwood Shores, CA, USA

Erik Johnson, Epicor Software

Outline

WS-I Schema Working Group Efforts Experience Report

Schema Producers / Authoring Toolkits Testing Resources

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 / AuthoringExtensibility & 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