W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2004

WSDL Language versus processor

From: David Booth <dbooth@w3.org>
Date: Thu, 26 Feb 2004 11:21:55 -0500
Message-Id: <5.1.0.14.2.20040226105921.033d33d0@localhost>
To: www-ws-desc@w3.org

Per my action item, I've been looking at how we can better distinguish in 
our spec between statements about the WSDL 2.0 language versus statements 
about what a WSDL processor must do.

Although I haven't finished this work item yet, I think I do have the basic 
ideas worked out and explained.  My thoughts so far are at:
http://www.w3.org/2004/02/dbooth-wsdl-lang-vs-proc.htm

For your convenience, a text version of the document follows.

----------------------------------------------------------

                       WSDL 2.0 Language Versus Processor

    David Booth, W3C Fellow / Hewlett-Packard


     [1]dbooth@w3.org
     This document:
     [2]http://www.w3.org/2004/02/dbooth-wsdl-lang-vs-proc.htm
     Last modified $Date: 2004/02/26 16:19:57 $

       [1] mailto:dbooth@w3.org
       [2] http://www.w3.org/2004/02/dbooth-wsdl-lang-vs-proc.htm

Abstract

    The problem of defining the WSDL 2.0 language is different from the
    problem of defining a conformant class of WSDL 2.0 processors.  There
    may be many kinds of processors, and the language specification should
    not try to dictate what they do.  Thus, the WSDL 2.0 language
    specification should not intermingle conformance constraints that
    pertain to WSDL processors.    However, both are important.  A clear
    and precise definition of the WSDL 2.0 language is important because
    it enhances interoperability between requester and provider agents,
    which both depend on a common interpretation of the WSDL document that
    governs their interaction.  And it is important to define a class of
    conformant WSDL 2.0 processors, because this can help improve the
    usability of WSDL, by permitting WSDL processor substitutability.
    This document recommends that the WSDL 2.0 specification include a
    section defining one or more classes of conformant WSDL 2.0
    processors.

Status

    This document has no official status.  Opinions are those of the
    author.  Comments are invited.

Table of Contents

      [3]Definitions
        [4]Logical WSDL Document
        [5]What Is Interoperability?
          [6]Disagreement about choice of WSD/endpoint
          [7]Disagreement about meaning of WSD/endpoint
          [8]Disagreement about application semantics
        [9]Requester and Provider Agent Interoperability ("Agent Interop")
        [10]WSDL Processor Substitutability
      [11]Analysis of Current WSDL 2.0 Specification Draft
        [12]The Meaning of a WSD
        [13]Optional Extensions and the WSDL 2.0 Language
        [14]Optional Extensions and WSDL 2.0 Processors
        [15]Alignment with WebArch Recommendations on Extensions
      To Do List

Definitions

   Logical WSDL Document

    By "logical WSDL document" I mean the infoset or set of components
    obtained from a WSDL document (i.e., after expanding any imports,
    includes, etc.). See
    http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0085.html for
    further explanation.
    Synonyms: "Sentence in the WSDL language", "WSDL sentence", "Web
    service description (WSD)", "logical WSD".

   What Is Interoperability?

    Roughly speaking, interoperability between a [16]requester and
    [17]provider agent occurs when they agree on both the mechanics and
    semantics of their intended interaction.  Since the problem we wish to
    avoid is actually the lack of interoperability, it is helpful to
    instead define what that means.
    Non-interoperability occurs either when the [18]requester and
    [19]provider entities do not agree on the mechanics of the interaction
    (such as the syntax, protocol or sequence of messages), or when they
    do not agree on the semantics of the interaction.  There are three
    ways this can occur:
     1. (Disagreement about choice of WSD/endpoint)  The requester and
        provider entities are unable to agree on a WSD and endpoint that
        is to govern their agent interaction.
     2. (Disagreement about meaning of WSD/endpoint)  The requester and
        provider entities agree on the WSD and endpoint that will govern
        their agent interaction.  However, they disagree about the
        intended interaction that the WSD denotes.
     3. (Disagreement about application semantics)  The requester and
        provider entities agree on the WSD and endpoint, and they agree on
        the intended interaction that the WSD denotes.  However, they
        disagree on the application semantics of the interaction.

      [16] http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#requesteragent
      [17] http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#provideragent
      [18] http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#requesterentity
      [19] http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#providerentity

    These three cases are discussed below.

     Disagreement about choice of WSD/endpoint

    If the requester and provider entities do not agree on the choice of
    WSD and endpoint that is to govern their agent interaction, then their
    corresponding agents will not be able to interact.   One way that this
    can occur is if one party wishes to use one WSD, but the other party
    (for whatever reason) does not like that WSD, perhaps because it uses
    features or extensions that the second party does not support.
    This can be viewed as a problem for negotiation between the requester
    and provider entities, just as these parties must agree on the
    application semantics of the interaction.  (If the parties cannot
    agree on what WSD and endpoint they will use for their corresponding
    agent interaction, then their agents cannot sensibly interact anyway.)
    The typical way for the requester and provider entities to negotiate
    what WSD/endpoint to use is for the provider entity to offer the
    entire WSD and application semantics on a take-it-or-leave-it basis,
    with the WSD containing a choice of one or more endpoints.  By
    offering such a WSD, the provider entity is implicitly agreeing to
    interact with the requester entity via any of the endpoints listed in
    that WSD.  And by selecting a particular endpoint from this WSD, the
    requester entity is implicitly agreeing to interact through this
    chosen endpoint according to the WSD and application semantics that
    were offered.
    Although this is not the primary issue of interop that we wish to
    address, it is important, and [20]WSDL processor substitutability can
    help to address it, as explained below.

     Disagreement about meaning of WSD/endpoint

    If the requester and provider entities agree on what WSD and endpoint
    to use, but they disagree about the intended interaction that this
    WSD/endpoint denotes, then their corresponding requester and provider
    agents still will not be able to interact (at least not correctly).
    Since the purpose of the WSD is to partially define the expected
    interaction between the requester and provider agents, this is the
    main kind of interop issue that this document addresses.  This is the
    issue of [21]Requester and Provider Agent Interoperability ("Agent
    Interop"), discussed below.

     Disagreement about application semantics

    Even if the requester and provider entities agree on the WSD and
    endpoint to use, and they agree on the intended interaction that the
    WSD denotes, they can still fail to interoperate because they have
    different understanding of the semantics of the interaction.  For
    example, one party may interpret "25.00" as US dollars and the other
    party may interpret it as Euros.
    The WSDL 2.0 specification can partially address this kind of interop
    problem by reinforcing [22]the TAG's advice on namespace documents and
    recommending that namespace documents SHOULD (directly or indirectly)
    contain definitive material on the meaning and purpose of the
    vocabularies that they define.  There are at least three kinds of
    namespaces pertaining to application semantics that WSDL authors are
    likely to introduce:
      * The wsdl:targetNamespace, which in essence identifies the
        application-defined semantics of the component names (operations,
        interfaces, service names, etc.) that are used in the WSDL
        document as a whole.
      * Any message syntax namespace used in defining a message
        vocabulary.  Since messages are what are actually transmitted
        between the requester and provider agents, the namespace of a
        message vocabulary in essence identifies the semantics of that
        message vocabulary.  (See [23]Semantics and WSDL for further
        explanation on what I mean by identifying the semantics as opposed
        to defining the semantics.)
      * Any extension namespace.

      [22] http://www.w3.org/TR/2003/WD-webarch-20031209/#namespace-docs
      [23] http://www.w3.org/2002/09/wsdl-semantics-dbooth/semantics_clean.htm

    The current draft of the WSDL 2.0 Core spec already includes the
    following [24]recommendation for the wsdl:targetNamespace:

      [24] 
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20.html?rev=1.9&content-type=text/html;%20charset=iso-8859-1#Definitions_XMLRep

    The target namespace represents an unambiguous name for the intended
    semantics of the WSDL Infoset. The targetNamespace URI SHOULD point to
    a human or machine processable document that directly or indirectly
    defines the semantics of the WSDL Infoset.

    The current draft of the WSDL 2.0 Core spec does not include such
    advice for message syntax namespaces or extension namespaces.  Similar
    advice could be added for them.
    Suggested change: Add a statement along the lines of

    For any namespace that is used any message syntax, the namespace URI
    SHOULD point to a document that directly or indirectly defines the
    semantics of the vocabulary defined that namespace.

   Requester and Provider Agent Interoperability ("Agent Interop")

    Agent interoperability is when the requester and provider agree on the
    intended interaction denoted by the WSD and endpoint that they have
    chosen to use.
    If an endpoint e in a logical WSDL 2.0 document wsd describes the
    intended interaction between a requester agent ra and a provider agent
    pa, then ra and pa are agent interoperable if they agree on the
    intended interaction through e that is denoted by wsd.
    (Of course, to have full interoperability, they will still need to
    agree on the application-defined semantics of the interaction.)

   WSDL Processor Substitutability

    WSDL processor substitutability refers to the ability, relative to a
    given task, to substitute a different WSDL processor and obtain
    substantially equivalent behavior.  In other words, if a WSDL
    processor p1 is used as part of a larger process that manipulates WSDL
    documents, then another WSDL processor p2 would be substitutable if p2
    could be plugged into that larger process in place of p1, and p2 would
    behave equivalently with respect to that larger process.
    It is worth noting that WSDL processor substitutability is not
    required to achieve agent interop.  Agent interop is about agreeing on
    the meaning of a WSD, whereas WSDL processor substitutability is about
    what a WSDL processor does with a given WSD.  However, WSDL processor
    substitutability can help the requester and provider entities
    negotiate which WSD and endpoint to use, because different processors
    may handle different sets of extensions or optional features: If the
    provider entity restricts itself to a certain well-known set X of
    features/extensions, and the requester entity uses an X-conformant
    WSDL processor (i.e., one that implements those feature/extensions),
    then the requester entity knows that it will be able to use the WSD
    offered by the provider entity.   (Or conversely, the provider entity
    knows that any requester entity with an X-conformant WSDL processor
    will be able to use its WSD.)

Analysis of Current WSDL 2.0 Specification Draft

   WSDL 2.0 Part 1 (Core Language)

    Version analyzed:
    http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?re
    v=1.9&content-type=text/html;%20charset=iso-8859-1
    Latest version:
    http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html

     Section 2.3.1.1.1 RPC Style (Rules for RPC Signature)

    The paragraph (with bullet items) beginning "Furthermore, the
    following rules MAY BE used to map between a message and a signature
    of a remote procedure call" proposes conventions for a WSDL
    processor.
    Suggested change: These should either be clearly marked as
    non-normative hints or moved to a conformance section.

     Section 3.1 Using W3C XML Schema Description Language

    The first paragraph states: "All processors MUST support XML Schema
    type definitions."
    Suggested change: Move to a conformance section.

     Section 6.1.1 Mandatory extensions

    The first paragraph was:

    Extension elements can be marked as mandatory by annotating them with
    a wsdl:required attribute information item (see 6.1.2
    requiredattribute information item) with a value of "true". Mandatory
    extensions are those that MUST be processed correctly by the WSDL
    processor. If a mandatory extension element is processed, the WSDL
    processor MUST either agree to fully abide by all the rules and
    semantics signaled by the extension element's qualified name, or
    immediate cease processing (fault). In particular, if the WSDL
    processor does not recognize the qualified name of the extension
    element, it MUST fault. If the WSDL processor recognizes the qualified
    name, and determines that the extension in question is incompatible
    with any other aspect of the document (including other required
    extensions), it MUST fault.

    Suggested changes:
    1. State @@somewhere@@:

    The extension is identified by the qname consisting of its namespace
    URI and its element name.    The meaning of the extension SHOULD be
    defined (directly or indirectly) in a document that is available at
    its namespace URI.

    2. Reword the existing paragraph to:

    Extension elements can be marked as mandatory by annotating them with
    a wsdl:required attribute information item (see 6.1.2
    requiredattribute information item) with a value of "true". A
    mandatory extension is an extension that may change the meaning of the
    WSDL 2.0 component to which it is attached, such that the meaning of
    that component is no longer defined by the WSDL 2.0 language
    specification. Instead, the meaning of a WSDL 2.0 component containing
    a mandatory extension is governed by the meaning of that extension.
    Thus, the definition of the component's meaning is delegated to the
    specification that defines the extension.

    3. Add to a conformance section:

    Mandatory extensions are those that MUST be processed correctly by the
    WSDL processor. If a mandatory extension element is processed, the
    WSDL processor MUST either agree to fully abide by all the rules and
    semantics signaled by the extension element's qualified name, or
    immediate cease processing (fault). In particular, if the WSDL
    processor does not recognize the qualified name of the extension
    element, it MUST fault. If the WSDL processor recognizes the qualified
    name, and determines that the extension in question is incompatible
    with any other aspect of the document (including other required
    extensions), it MUST fault.

     Section 6.1 Element based extensibility

    The fifth paragraph is currently:

    An extension element is said to be processed if a WSDL processor
    decides (through whatever means) that its parent (an element
    information item in the "http://www.w3.org/@@@@/@@/wsdl" namespace)
    will be processed. Note that it is possible for WSDL processors to
    process only a subset of a given WSDL document. For instance, a tool
    may wish to focus on interfaces and operations only, and will
    consequently skip bindings.

    Suggested changes:
    @@unfinished@@

     Section 6.2 Attribute-based extensibility

    @@Add something to say what they mean?@@

     The Meaning of a WSD

    Add something like:

    This specification defines both the WSDL 2.0 language (i.e., the set
    of legal sentences in this language and their semantics) and a class
    of WSDL 2.0 conformant processors.  A Web service description (WSD) is
    the set or components represented by a legal sentence in the WSDL 2.0
    language, as specified in this document.  Endpoints in the WSD
    describe alternate ways for a provider agent and a hypothetical
    requester agent to interact.  Each endpoint partially defines the
    expected interaction betweenthe provider agent and the hypothetical
    requester agent.  @@ Need to explain why it only "partially defines"
    the interaction. @@
    @@ Need to describe the dependency chain of meaning: The meaning of
    the endpoint depends on its constituents.  However, the meaning of the
    wsdl:definitions does not depend on the meaning of its endpoints.
    (Thus a processor only needs to process the endpoint that it needs.)
    @@
    @@ Need to say that a WSD makes a set of assertions about the
    interaction between the parties in the MEP. (Usually two parties)  @@

   Optional Extensions and the WSDL 2.0 Language

    The key to understanding optional extensions is to remember that we
    are using the "open world" assumption: the WSD does not fully define
    the behavior of interacting requester and provider agents, but only
    partially defines it.  In other words, if we assume that the WSD
    represents a set of assertions about the behavior of an interacting
    requester and provider agent, then those agents could have additional
    behavior (or additional assertions about their behavior) that is not
    described by the WSD.
    As a simple example, the WSD may contain a message schema that defines
    the type of the <price> element to be a number.  Effectively, it makes
    an assertion like:

    "Element <price> contains a number."

    However, the schema itself does not indicate that this number should
    be interpreted as US dollars.  Additional documentation may further
    define the application-defined semantics of the interaction, in
    essence adding assertions like:

    "The units for <price> are US dollars."

    Similarly, even the message exchange pattern (MEP) only partially
    constrains the sequence of messages between the requester and provider
    agents.  The MEP for a request-response interaction, for example,
    asserts:

    "If the requester agent sends the provider agent a message, then the
    provider agent will send a reply message."

    However, if the parties agree, then the requester and provider agents
    could have additional interaction beyond what the MEP describes.  For
    example, the WS could have a special feature such that every time the
    WS receives a request, it immediately sends back a preliminary reply
    message indicating how soon the full response can be expected.  Then,
    when the full response is ready, it sends back the full response in a
    separate message.  In other words, both the request and response
    messages are still present as asserted by the MEP, but the preliminary
    reply is inserted into the request-response pattern as additional
    behavior.  This additional behavior

    "If the requester agent sends the provider agent a message, then the
    provider agent will also send a preliminary message, prior to sending
    the reply message."

    Of course, the requester and provider agents will only be able to
    interoperate on this basis if: (a) the requester agent discards any
    unexpected messages; or (b) the parties have previously agreed to this
    special behavior (which would be no more encumbering that agreeing on
    the application-specific semantics of the interaction, which the
    parties must do out-of-band anyway).
    As another example, suppose you have a WS that will happily speak SOAP
    1.2 over HTTP, but you want to let users know that it can also speak
    some custom whiz-bang protocol.  To do so, the WSD should contain a
    SOAP 1.2 over HTTP binding and endpoint.  This endpoint effectively
    makes the assertion:

    "This WS knows how to speak SOAP 1.2 over HTTP."

    In addition, the WSD should specify an optional extension to indicate
    that this WS can also speak the whiz-bang protocol.  The optional
    extension effectively adds the assertion:

    "This WS knows how to speak the whiz-bang protocol."

    Any requester agent that understands the optional extension can use
    the whiz-bang protocol if it chooses.  But it can also safely ignore
    it and use the standard SOAP 1.2 over HTTP binding and endpoint.  The
    key point is that the optional extension has not changed the semantics
    of the rest of the WSD.  It has merely provided additional assertions
    about the capabilities of the WS.
    An optional extension therefore may provide additional information
    about the expected interaction of the requester and provider agents.
    An optional extension DOES NOT invalidate or change the meaning of the
    component to which it is attached.

   Optional Extensions and WSDL 2.0 Processors

    In defining a class of conformant WSDL 2.0 processors, what should we
    say about optional extensions?  It depends on what kind of processor
    we wish to define.
    In some cases, catching as many errors as possible may be desired.
    For example, a WSDL processor that is attempting to verify the
    complete validity of the WSD and check it for possible mistakes should
    NOT ignore an optional extension that it does not recognize, since the
    unrecognized extension may represent a spelling error.
    In other cases, non-essential errors may be problematic to report.  In
    those cases, it may be preferable to stipulate that the WSDL processor
    MUST IGNORE any optional extension that it does not recognize, since
    the processor could safely ignore it without misunderstanding the
    meaning of the rest of the WSD.

   Alignment with WebArch Recommendations on Extensions

    The above approach to optional extensions aligns with the WebArch
    document's advice on the use of "MUST IGNORE" and "MUST UNDERSTAND"
    extensibility mechanisms (
    http://www.w3.org/TR/2003/WD-webarch-20031209/#pr-unknown-extension ),
    though I think it provides more explanation of how/why these
    approaches work than the WebArch document includes.  Essentially, if a
    statement in a language is viewed as making a set of assertions, AND
    the language makes the "open world" assumption, then a "MUST IGNORE"
    extension is viewed as introducing additional assertions that must not
    contradict or invalidate any existing assertions that are defined by
    the language.  On the other hand, "MUST UNDERSTAND" may change the
    existing semantics of the language and thus may invalidate existing
    assertions.

To Do

     1. Amy's message on conformance, and Jacek's proposal:
        http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0110.html
        http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0121.html
     2. Need to add something about delegation of specification
        authority.  I.e., WSDL 2.0 spec defines the meaning of a WSDL 2.0
        document, but for an extension, the authority for defining the
        meaning of a component(?) is delegated to the definition of that
        extension.
     3. Add something about dependency graph determining what is
     4. Finish searching in the WSDL spec for all mentions of:
        MUST, SHOULD, MAY, error, processor, warning
     5. Mention conformance testing: (1) testing requester and provider
        agents; (2) testing WSDL processors.
     6. Add GlenD's other example (if he reminds me what it was).  :)




-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Thursday, 26 February 2004 11:22:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:02 UTC