- 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