WSI Submission - PowerPoint PPT Presentation

1 / 10
About This Presentation
Title:

WSI Submission

Description:

An open industry effort chartered to promote Web Services interoperability ... Implementers need to create derivative schemas and compose schemas into WS descriptions ... – PowerPoint PPT presentation

Number of Views:19
Avg rating:3.0/5.0
Slides: 11
Provided by: ErikJo9
Category:

less

Transcript and Presenter's Notes

Title: WSI Submission


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

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

3
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

4
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?

5
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

6
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 dont want to serialize objects
    others do
  • Some want RPC semantics others dont
  • Few implementers use XML Schema validation
  • Some validation aspects get handled by
    combinations of type serializers, SOAP
    processors, and hand-rolled code

7
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

8
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

9
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

10
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

11
WS-I Submission
  • Thanks
Write a Comment
User Comments (0)
About PowerShow.com