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: Martin Gudgin <marting@develop.com>
Date: Fri, 15 Mar 2002 19:28:22 -0000
Message-ID: <000001c1cc84$8c9eeee0$b47ba8c0@zerogravitas>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>, "Noah Mendelsohn" <noah_mendelsohn@us.ibm.com>
Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>

----- Original Message -----
From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
To: "'Martin Gudgin'" <marting@develop.com>; "Noah Mendelsohn"
<noah_mendelsohn@us.ibm.com>
Cc: <xml-dist-app@w3.org>
Sent: Friday, March 15, 2002 1:21 PM
Subject: RE: Rework on SOAP 1.2 Part 2: Section 2 and 3


> Hummm.... feels like a bit of a fudge to me... along the lines of:
>
> "All EII's repesent edges, and some edges represent nodes."

No. All EIIs represent edges, and some EIIs represent nodes.

>
> For the two examples I give what graphs would you draw. (simplify if needs
> be... I know drawing these is tedious).

I don't see why collapsing your second example such that edgeC becomes the
parent of edgeD and edgeF is a problem. You obviously don't think it's a
problem for terminals, why should it be a problem for non-terminals?

Per the encoding rules your second example ( relabeled );

<structA>
  <edgeB>terminalB</edgeB>
  <edgeC>terminalC</edgeC>
  <edgeD>
    <structE>
      <edgeF>terminalF</edgeF>
      <edgeG>terminalG</edgeG>
    </structE>
  </edgeD>
</structA>

the resulting graph would look like this ( per the encoding rules
described );


       edgeB +-----------+
     +------>+"terminalB"|
     |       +-----------+
     |
+----+-----+ edgeC +-----------+
|"nontermA"+------>+"terminalC"|
+----+-----+       +-----------+
     |
     | edgeD +----------+ structE +----------+ edgeF +-----------+
     +------>+"nontermD"+-------->+"nontermE"+------>+"terminalF"|
             +----------+         +----+-----+       +-----------+
                                       |
                                       | edgeF +-----------+
                                       +------>+"terminalE"|
                                               +-----------+

Hope this helps,

Gudge

>
> Stuart
>
> > -----Original Message-----
> > From: Martin Gudgin [mailto:marting@develop.com]
> > Sent: 15 March 2002 13:07
> > To: Williams, Stuart; 'Jean-Jacques Moreau'; Noah Mendelsohn
> > Cc: xml-dist-app@w3.org
> > Subject: Re: Rework on SOAP 1.2 Part 2: Section 2 and 3
> >
> >
> > All element information items represent edges. For a graph *node* with
> > multiple inbound edges exactly one of the 'edge' EIIs will represent the
> > node. The other edge EIIs will ref the EII that represents the node.
> >
> > So an EII that represents a node also represents one inbound edge to
that
> > node.
> >
> > Hope this helps
> >
> > Gudge
> >
> > ----- Original Message -----
> > From: "Williams, Stuart" <skw@hplb.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>
> > Sent: Friday, March 15, 2002 11:44 AM
> > Subject: RE: Rework on SOAP 1.2 Part 2: Section 2 and 3
> >
> >
> > > 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 19:50:06 GMT

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