W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

RE: Rework on SOAP 1.2 Part 2: Section 2 and 3

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Fri, 15 Mar 2002 11:44:12 -0000
Message-ID: <5E13A1874524D411A876006008CD059F192A22@0-mail-1.hpl.hp.com>
To: "'Jean-Jacques Moreau'" <moreau@crf.canon.fr>, Martin Gudgin <marting@develop.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
Cc: xml-dist-app@w3.org
I agree... this is great work.

I think I have a problem with section 3.1.1. which seems to contain a
contradiction. The first sentence states: "Each graph edge is encoded as an
element information item and each element information item represents a
graph edge." The problem being the statement that each element information
item represents a graph edge. The contractiction arises from the first entry
in the itemised list that follows: "...then the element information item is
said to represent a node in the graph and the edge terminates at that node."
This now states that element information items can also represent graph
nodes - contraticting the initial sentence.

There is perhaps more 'strippyness' here... (one form of RDF syntax looks
very like this too)

   <node>
      <edge>
         <node>
            <edge>terminalNodeTypedLiteral</edge>
            <edge/>
         </node>
      </edge>
      <edge/>
      <edge/>
   </node>

Consider this graph:

          edgeB       +-------------+
      +-------------->+ "terminalB" |
      |               +-------------+
      | 
 +----+----+  edgeA   +-------------+
 | structA +--------->+ "terminalA" |
 +----+----+          +-------------+
      |
      |    edgeC      +---------+ edgeD  +-------------+
      +-------------->+ structB +------->+ "terminalD" |
                      +----+----+        +-------------+
                           |
                           |   edgeF     +-------------+
                           +-------------+ "terminalE" |
                                         +-------------+

I think that is appealing to encode the nested structure something like:

	<structA>
		<edgeA>terminalA</edgeA>
		<edgeB>terminalB</edgeB>
		<structB>
               <edgeD>terminalD</edgeD>
               <edgeF>terminalF</edgeF>
            </structB>
 
	</structA>

however in doing so we loose the graph edgeC. We need to introduce edgeC as
an element to maintain the phasing of the stripes, thus:

  <structA>
    <edgeA>terminalA</edgeA>
    <edgeB>terminalB</edgeB>
    <edgeC>
      <structB>
        <edgeD>terminalD</edgeD>
        <edgeF>terminalF</edgeF>
      </structB>
    </edgeC>
  </structA>

Does this make any sense or is this a complete non-problem?

Best regards

Stuart

> -----Original Message-----
> From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr]
> Sent: 15 March 2002 09:12
> To: Martin Gudgin; Noah Mendelsohn
> Cc: xml-dist-app@w3.org
> Subject: Re: Rework on SOAP 1.2 Part 2: Section 2 and 3
> 
> 
> +1, tremendous job!
> 
> Two questions:
> 
>    * Section 3.1.1, bullet 1, "then the element information 
> item is said to
>      represent"
>      Should it be read as "this element information item" 
> (i.e. "the edge
>      element information item") or "the node element 
> information item"?
>    * Section 3.1.2, Unicode
>      Didn't we say recently UTF-8 or UTF-16?
> 
> Jean-Jacques.
> 
> Tim Ewald wrote:
> 
> > I love this new version, especially the language in section 2 that
> > clarifies the roll of the SOAP data model relative to XSD. 
> I also like
> > the clarifications in section 3 about the precise meaning 
> of xsi:type in
> > the context of the SOAP encoding.
> 
Received on Friday, 15 March 2002 06:46:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT