- From: Martin Gudgin <marting@develop.com>
- Date: Fri, 15 Mar 2002 19:28:22 -0000
- 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 UTC