Encoding test case template

 Hi, this is a template that the third group from the f2f proposes
for describing Encoding test cases. This mail also lists an issue
that is important for describing test cases for Encoding. The
issue is not too important for the spec itself, IMO.
 Noah and other members of the third team, please check if I have
written with sufficient precision what we had discussed.

 Encoding test cases introduction:
 The test cases use a simple application that deserializes
receives a SOAP envelope and outputs the data graph resulting from
deserializing the contents of the Body. The output form depends on
the particular implementation, it must be translatable to plain
english description of a graph in the SOAP Data Model.
 Because of the possible variation in the serialized form of a
given data graph (usually an infinite number of variations - e.g.
the integer 42 can be written as 42, 042, 0042, 00042 etc.), we
only present deserialization test cases. [We might attempt to
formulate serialization test cases, but sufficient formulation
seems unattainable here, see discussion at the end of this
message.]

 The template:
 Name: the name of the test case (e.g. Simple types)
 Description: the description of the test case (e.g. This case
tests the deserialization of values typed to XML Schema Datatypes
builtin simple types.)
 Input envelope: here goes the envelope, e.g.
  <env:Envelope
       xmlns:env="<.../Envelope>"
       xmlns:app="urn:SOAP-encoding-testing-application"
       xmlns:xsi="<xml-schema-instance-ns-uri>"
       xmlns:xsd="<xml-schema-simple-types-ns-uri>">
    <env:Body>
      <app:a xsi:type="xsd:string">foo</app:a>
      <app:b xsi:type="xsd:int">42</app:b>
    </env:Body>
  </env:Envelope>
 Resulting data graph: a plain-English description of the data
graph represented in the Envelope. (e.g. the Body contains two
independent edges, one named "a" in the namespace
"urn:SOAP-encoding-testing-application" leading to the value "foo"
typed "string" in the XML Schema namespace, the second named "b"
in the namespace "urn:SOAP-encoding-testing-application" leading
to the value 42 typed "int" in the XML Schema namespace.)

 ISSUE
 In data serialization, what is the root? What we have are nodes
(values) and edges (named or indexed accessors).
 For example in the RPC case, where there is a struct named after
the called procedure - what is the root of serialization from the
graph point of view?
 Is it the named edge? (The serialization tree would start with
an edge leading from nowhere to the struct value.)
 Or is it an implied root node? (In this case the Body, but the
Body element is not serialized using the Encoding rules.)
 This issue affects how the description of the resulting data
graph in the test cases are to be written, which would be either
of the following two forms:
 1) "The Body contains an edge named 'foo' and leading to a value
typed 'xsd:int' with the value 42."
 2) "The Body is linked by an edge named 'foo' leading to a value
typed' xsd:int' with the value 42."
 Both approaches feel weird because the first has an edge leading
from nowhere and the second talks about the Body in Encoding
terms while the Body is not serialized using the Encoding.

 Now to the discussion of serialization test cases: If we present
a data graph and tell the implementation to serialize it, the
implementation can do that in one of (too) many different ways.
To try to handle this a few approaches come to my mind:
 1) define a canonical serialization - overkill.
 2) say vaguely "the serialization will result in XML document
whose meaning is the same as of the document that we provide" -
similar to the following one,
 3) say "the serialization will result in an XML document, which
deserialized will result in the same data graph as presented" -
this tests interoperability of the implementation of the
serializer with the implementation of the deserializer, but this
is not the aim of the Test cases, is it?
 As Noah has pointed out inside the group #3 at the F2F, XML
Schema group has also decided not to provide testing for XML
Schema generators.

 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/

Received on Sunday, 9 December 2001 14:57:58 UTC